On 22.04.2011 23:07, Johan Corveleyn wrote:
> On Thu, Apr 21, 2011 at 3:07 PM, Daniel Shahaf <d.s_at_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
Received on 2011-04-22 23:16:29 CEST