Johan Corveleyn wrote on Tue, May 03, 2011 at 21:49:48 +0200: > On Mon, Apr 25, 2011 at 11:26 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > Johan Corveleyn wrote on Mon, Apr 25, 2011 at 23:10:21 +0200: > >> 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. > >> > > > > Sorry for not being clear. > > > > In my example I intended 'foo' and 'Foo' to be two separate lines of > > history. > > > > % svnadmin create r1 > > % svn co file://`pwd`/r1 wc1 > > % cd wc1 > > % svn mkdir iota > > % svn ci -m r1 > > % svn rm iota > > % svn mkdir IOTA > > % svn ci -m r2 > > % svn up -r2 > > % option #1: svn up -r1 iota > > % option #2: svn up -r1 iota IOTA > > > > For option #1, I specified 'iota', so I expect svn to error out saying > > "You asked me to create ./iota but I can't because ./IOTA exists" (never > > mind whether or not it's versioned). > > I'm confused. If you type "svn up -r1 iota", the iota is a target of > the PATH variety, or in any case you're trying to address something in > the working copy. At this point there is no ambiguity: you're actually > referring to IOTA (the on-disk truepath), because what else is there > (there is no iota present on disk, nor in the wc metadata)? >
There is ^/iota@1. Just take IOTA out of the picture and try it: % svnadmin create r1 % svn co file://`pwd`/r1 wc1 % cd wc1 % touch iota && svn add iota % svn ci -m r1 iota % svn rm iota % svn ci -m r2 % svn up -r2 % svn up -r1 iota > So you're really asking to update IOTA to r1, in which it didn't > exist. No, I'm asking to restore 'iota' from r1, in which it did exist. > So this is a perfectly valid operation, which would result the > deletion of IOTA (and nothing else). > > > Option #2 is what I'd expect to work to get me iota@1 (at the expense of > > shifting IOTA@2 to not-present(?) state, but that's the best I can do > > given the filesystem's limitations). It's probably a bit tricky unless > > we can ensure the editor sends IOTA before iota, though... > > No, this is identical to option #1, I think. There is no iota on-disk, > nor is there in wc-metadata, so you can only be referring two times to > IOTA. > (see above) > -- > Johan
