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>
Cheers,
--
Johan
Received on 2011-04-22 23:08:20 CEST