On May 21, 2014, at 09:48, Dan Ellis wrote: > On Wed, May 21, 2014 at 3:22 AM, Ryan Schmidt wrote: > >> On May 20, 2014, at 17:02, Dan Ellis wrote: >> >>> I'm attempting to copy a file from a working copy to the server, but using >>> an incorrect case for one of the folders in the path. The paths all exist >>> and everything works fine using correct case. In the example below, "FOO" >>> exists on the server as "foo". >>> >>> (Case 1) >>> c:\Project_files\sandbox>svn copy bar.c >>> http://svr/repo/some_project/FOO/bar.c -m "text commit" >> >> You're trying to create something in the non-existent directory FOO, which >> is an error. It never gets to the point of calling your hook script. (The >> message might be clearer if it said "Directory not found: …, path >> '/some_project/FOO'" instead of "File not found: …, path >> '/some_project/FOO/bar.c'".) >> >>> If I use --parents to create the path (in case it doesn't exist): >>> >>> (Case 3) >>> c:\Project_files\sandbox>svn copy --parents bar.c >>> http://svr/repo/some_project/FOO/bar.c -m "test commit" >>> ** ERROR-CASE: Clash: '/some_project/FOO' '/some_project/foo' >> >> You've asked Subversion to create a directory FOO when a directory foo >> already exists, which would be fine, except your hook script prevents case >> collisions. > > My question revolves around why the different behavior/messages when the only > difference is when --parents is included. One case bombs out with a cryptic > message (svn: E155011: File 'C:\Project_files\sandbox\bar.c' is out of date) > and the other triggers a pre-commit check. Both would seem to have identical > implementation accept when a directory is not found (--parents would create > it). Why didn't case 1 trigger the pre-commit check? Granted, the script in > question may be out of scope of this list.
The pre-commit hook script is only called if Subversion's internal checks already passed; if the internal checks fail, there's no reason to call the pre-commit hook script since the commit will fail regardless of the hook script's outcome. The internal check that failed in this case was that you asked Subversion to put a file into a nonexistent directory. I agree the error message could be improved, as I said above. I can reproduce it with a simple script: $ cd /private/tmp $ svnadmin create repo $ REPO=file://$(pwd)/repo $ svn co $REPO wc Checked out revision 0. $ cd wc $ touch file $ svn add file A file $ svn ci file -m "" Adding file Transmitting file data . Committed revision 1. $ svn up Updating '.': At revision 1. $ svn cp file $REPO/nonexistent/path/to/file -m "" Adding copy of file svn: E155011: Commit failed (details follow): svn: E155011: File '/private/tmp/wc/file' is out of date svn: E160013: File not found: transaction '1-1', path '/nonexistent/path/to/file' I think it would be clearer if the message said: Adding copy of file svn: E155011: Commit failed (details follow): svn: E160013: Directory not found: transaction '1-1', path '/nonexistent' >>> As I would expect, I cannot perform an "svn info" on the incorrect-cased >>> path. I was hoping I could do an "svn info" to test/determine what the >>> case corrected path is, but will have to try an "svn copy --parents" first >>> and if it fails due to a case clash, retry with the returned clash info. >>> Is there a better way to accomplish this? I do understand this is more of >>> a corner use case, especially since Subversion is (properly IMO) designed >>> around case sensitivity. >> >> What exactly are you trying to accomplish? If the problem is that you don't >> know the names (or cases) of the directories in the repository, then you can >> use "svn ls" to find out. > > Doing an "svn ls" is burden-some when you have a lengthy path that you want > to discover the case sensitive version of. If you had A/b/C/d/E for a path, > you'd have to "svn ls" on the repo to find "A" vs "a" then do another for "B" > vs "b" etc. I'd like to know of the easiest method to discover A/b/C/d/E vs > doing an svn copy --parents to have the server side report back the case > sensitive version of it. Plus, from a previous email, there's no stock way > to do "svn list" and return only the directory listing (you have to wade > through all the files as well). > > I guess the normal and usual use case is having a working copy checkout so > you can locally navigate the repo structure. In our case, we are doing an > archive type of operation where we really do not want a local WC due to size > and just operation on the repo directly. svn copy works great in this case > with the exception of users getting case confused. I don't understand how you get into the situation of knowing the letters in the names of directories in the repository but don't know their case.
