subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: Incorrect error message on svn copy? Advice?
Date Thu, 22 May 2014 02:00:13 GMT
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

$ 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
> 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.

View raw message