[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 25 Apr 2011 18:03:48 +0300

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
> anyway. So I'd expect companies that have to support case-insensitive
> clients to keep real case-clashes out of their repository (or fix them
> as soon as they are discovered).
> So maybe "case-only rename" (and perhaps "case-only replace"
> (delete+add w/o history)) is the only use-case we need to go for. But
> apart from commit, we should maybe also make "revert" possible, as
> well as adding to and removing from changelists ... (hm, commit would
> be the main thing I guess, revert can always be done in two steps
> (revert the add, then the delete), changelists ... oh well).

Another use-case:

When r1 contains a file 'Foo', r2 contains a file 'foo', the working
copy is at uniform revision r2, and the user types 'svn up -r1 Foo'.

There is also a variant where Foo_at_r1 is a directory rather than a file,
but that's getting contrived.

> I'd love to hear some more input ...
> Cheers,
Received on 2011-04-25 17:04: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.