On Fri, 22 Apr 2011 23:07 +0200, "Johan Corveleyn" <jcorvel_at_gmail.com> 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
The other side of the coin is calling it an intentional limitation resulting from our self-imposed layered (multiple libraries) design.
> 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.
>
Or, more simply, move the truepath canonicalization out of the cmdline client: it has no right to second-guess which case (among the N cases which may be present in the wc the user had in mind (e.g., if 'Foo' 'FOo' 'FOO' all exist, but their parent dir is at depth empty (and let's assumed an unversioned 'foo' exists, too))).
> 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?
>
Yeah, feel free. I didn't want to call the option --bikeshed in the previous email because that's non-self-describing.
And, by the way... I was only half joking. I had in mind cmd.exe users when I wrote this --- and IIRC they wouldn't have to quote the ' in the option name --- but I had overlooked people using a native-windows svn.exe from a cygwin shell (who \would\ have to quote the ').
> 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.
Correct. And, moreover, if you wrote
% svn info \"foo\"
then svn would look for a file called "foo" (*including* the quotes), since " is a valid pathname character. (Similar example: 'git clone . ssh://foo.example.com/bar' does 'mkdir ssh:/'. (The correct syntax would use 'push'.))
> 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>
>
Feel free to suggest some magic syntax, like ^/. Or just make it the default --- as per my example above, this may be argued to be a bug in the cmdline client, which allows you to flip the default without waiting to 2.0.
> Cheers,
> --
> Johan
>
Received on 2011-04-23 10:56:09 CEST