On Mon, Apr 25, 2011 at 5:03 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Johan Corveleyn wrote on Mon, Apr 25, 2011 at 01:08:24 +0200: >> 2011/4/22 Branko Čibej <br...@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@r1 is a directory rather than a file, > but that's getting contrived.
And I guess 'Foo' no longer exists in r2, and 'foo' didn't exist in r1? Maybe 'Foo' got renamed to 'foo'? Or maybe there is no historical relationship? Anyway, I think this also works right now, without any special tricks: - 'svn up -r1 Foo' gets canonicalized to 'svn up -r1 foo', the file on-disk, and currently present in the working copy. - If 'foo's ancestor is 'Foo', 'foo' gets deleted and 'Foo' is downloaded from the repository, by the update editor. The update editor currently has no problems with handling case-only renames on case-insensitive filesystems. Cheers, -- Johan
