On 22.04.2011 23:07, Johan Corveleyn wrote: > On Thu, Apr 21, 2011 at 3:07 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: >> Johan Corveleyn wrote on Mon, Apr 18, 2011 at 20:01:20 +0200: >>> - In fact: the same problem holds true for other commands as well: how >>> to revert both sides of this move? Ok, one can revert in two steps ... >>> >>> - Maybe a more general solution is needed, so all commands can >>> adequately see which path the user actually means? The "truepath" >>> corresponding to a given path (modulo case), or really the path in the >>> case given by the user? A shot in the dark: (1) first look in the >>> wc-db - if the path matches a path in the wc-db, accept it as is, else >>> (2) convert it to its truepath (path on the filesystem that matches >>> modulo case). Except for "svn move", as implemented in this patch ... >>> >> How about >> >> * default: whatever we do today >> (so, convert all arguments (including --targets) to truepath). >> >> * svn --I-love-mysterious-case-errors-so-don't-convert-to-truepath: >> don't convert to truepath at all, just pass arguments straight down >> the library stack. If you specify 'Foo' and the wc has 'foo', you get >> a normal "'Foo' does not exist" error. >> >> Among other things, this avoids calling into the wc during argument >> parsing. <handwave>I also think it will allow for fixing at least two >> of the issues raised in this thread.</handwave> > Hmmm, not sure. I understand the "avoids calling into the wc during > argument parsing" argument. But, with my user-hat on, that sounds like > an implementation detail, unnecessarily constraining the tool. Since > svn allows me to address working-copy items, which are not necessarily > present as local files on disk, and those wc-items are more > "fine-grained" than the on-disk paths, it makes sense to me that svn > first checks if the user isn't actually trying to address a wc-item, > before trying to fold it into an on-disk path. That is, everywhere > where a wc-item is possible as an argument. > > But maybe I'm getting carried away a bit :-). A specific option would > probably solve the issue much more easily at the expense of some minor > ugliness. And you're right, allowing the user to specify that paths > are to be interpreted literally, would probably already fix two of the > issues. > >>> - Note that the above problem is already present now on trunk (without >>> my patch): since we can now represent case-clashing paths in the WC >>> even on a case-insensitive filesystem. (See Bert's example in [2], >>> "svn ren TODO todoQ; svn ren todoQ todo"). >>> >> P.S. The long --option name should be shortened before commit, but I'm >> +1 on not removing the single quote before commit; just leave it in >> there literally. > Heh :-). I hope you're joking. How about --literal-paths or something > like that? > > Your "single qoute" made me think of something else: can we avoid a > special option, and specify that paths which are quoted (single, > double, ... whatever works) are to be interpreted literally? Probably > not, I guess, since shells tend to process those things before svn > sees them. But who knows, maybe there is a nice (cross-platform) way > to "escape" path arguments so we know not to fold them to truepath? > </daydreaming>
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. -- Brane
