[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

case-change FAQ entry (was: svn commit: r1175524 - /subversion/site/publish/faq.html)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sun, 25 Sep 2011 21:09:14 +0200

Regarding the FAQ entry "How do I change the case of a filename?", I
noticed that there is more that can/should be changed than just
updating it with the case-changing Windows-support in 1.7. Since I
don't know the history about some of these things, I'm checking here,
before making more changes ...

1) I now changed it to say that you can do a simple case-change with
1.7 on Windows. Apart from <=1.6 on Windows, I thought it's also still
a problem on other OS'es with case-insensitive filesystems (because of
the lack of truepath support in APR on those OS'es). Is that correct?
Or is that just too much detail?

2) The FAQ entry still says:
Both ways will leave Windows working copies with problems, however,
because Windows can still get confused when trying to update the
conflicting filenames. (You'll get a message like svn: Failed to add
file 'File.java': object of the same name already exists). One way of
fixing the problem is to delete your working copy and check out again.
If you do not want to do this, you must perform a two step update.

Is that still the case? I've never experienced this problem (I'm a
user since 1.5). ISTR that someone said this is no issue anymore
because deletes are handled first, before adds. Is that correct? So
maybe that's only a problem with (very) old clients, in which case we
can remove that explanation?

3) At the end it says:
To prevent the problem from occurring in the first place, you can
create a pre-commit hook that calls the file
check-case-insensitive.pl. That file lives in the Subversion source
tarball, in the directory contrib/hook-scripts.

I think that should be reworked a bit to tell about the specific
problem of case-conflicting filenames being present simultaneously in
the repository (case-changes by themselves are not a problem). In
which case this pre-commit hook is useful to prevent it....

Besides: it's 'check-case-insensitive.py', not '.pl' (and it requires
python bindings). And is the reference to the source tarball correct?
If not, where can people find it?


On Sun, Sep 25, 2011 at 8:39 PM,  <jcorvel_at_apache.org> wrote:
> Author: jcorvel
> Date: Sun Sep 25 18:39:38 2011
> New Revision: 1175524
> URL: http://svn.apache.org/viewvc?rev=1175524&view=rev
> Log:
> * publish/faq.html
>  (case-change): Update faq entry to reflect that changing case on Windows
>   is supported from 1.7 onwards.
> Suggested by: danielsh
> Modified:
>    subversion/site/publish/faq.html
> Modified: subversion/site/publish/faq.html
> URL: http://svn.apache.org/viewvc/subversion/site/publish/faq.html?rev=1175524&r1=1175523&r2=1175524&view=diff
> ==============================================================================
> --- subversion/site/publish/faq.html (original)
> +++ subversion/site/publish/faq.html Sun Sep 25 18:39:38 2011
> @@ -1572,8 +1572,13 @@ problem at all.  Just move the file to t
>  svn&nbsp;mv&nbsp;file.java&nbsp;File.java
>  </pre>
> -<p>But this won't work in a case-insensitive operating system like
> -Windows.  In Windows you can accomplish this by copying the file
> +<p>From Subversion 1.7 onwards, this also works on Windows, even though
> +it's using a case-insensitive filesystem.</p>
> +
> +<p>If you are using Subversion 1.6 or older on Windows, or if you're
> +using a case-insensitive filesystem with an operating system other than
> +Windows, this technique won't work.  In this case, you can accomplish
> +this by copying the file
>  somewhere temporary, deleting the file from Subversion, then adding
>  the copy with the correct case.  Or a better way is to perform a move
>  operation with Subversion URLs.  Using URLs is recommended, because it
Received on 2011-09-25 21:10:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.