subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Ellis <danelli...@gmail.com>
Subject Re: Incorrect error message on svn copy? Advice?
Date Wed, 21 May 2014 14:48:40 GMT
On Wed, May 21, 2014 at 3:22 AM, Ryan Schmidt <
subversion-2014@ryandesign.com> 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.

>
> > 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 appreciate the feedback.

Thanks
Dan

Mime
View raw message