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

Re: [PATCH] First step for issue #3702 (case-only renames on Windows) - now blocked by libsvn_client

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 25 Apr 2011 22:51:36 +0200

On Mon, Apr 25, 2011 at 4:56 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Mon, Apr 25, 2011 at 01:08:24 +0200:
>> 2011/4/22 Branko Čibej <brane_at_e-reka.si>:
>> > Meh. For now, just hack a special case so that committing one half of a
>> > case-only rename will automagically commit the other half. Shouldn't be
>> > too hard to do, and it's almost impossible to do the wrong thing --
>> > after all, you're constrained by a) staying in the same directory, and
>> > b) both halves of a rename resolving to the same on-disk file on a
>> > case-insensitive file system.
>> Sounds like another option. A small change here and there to make
>> case-only renames work specifically (and not solve the more general
>> problem of fixing path-guessing via wc-db or truepaths).
>> The fact of the matter is that, for sane setups/companies,
>> case-clashes are going to be really rare, *except when doing case-only
>> renames*. A repository holding 'Foo', 'FOo' and 'FOO' would be a
>> repository that's un-checkoutable on a case-insensitive filesystem
> Un-checkoutable at depth >= svn_depth_files (assuming those 'foo' are
> files rather than directories).
> It makes perfect sense to me to have, say, both trunk/config.txt and
> trunk/CONFIG.txt, and tell people to do
>        svn up --set-depth=exclude config.txt     # remove the uppercase one
>        && svn up --set-depth=infinity config.txt # pull the lowercase one
>        ,
> for example.  It's a very cheap and effective way of ensuring at most
> one of the conflicting config.txt files is present.
> "Case-insensitive filesystems: it's not a bug, it's a feature."
> ---
> I'm not going to guess whether (and how many) people use Subversion this
> way; I'm only saying that the above workflow allows for coexisting
> case-clashing files and is supported by our released code.

Ok, disregarding for a second that I think this is pretty contrived
:-), I think this works perfectly well right now AFAICS. Because you
first (have to) exclude/remove the one that's currently on-disk, there
is no longer any truepath conversion going on after that. So the user
is then free to choose whichever of the case-clashing files to get
from the repository. There is no need to enable the user to specify a
case-clashing file (wc-item) while another one is on-disk.


Received on 2011-04-25 22:52:27 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.