On Sat, 23 Apr 2011 11:55 +0300, "Daniel Shahaf" <d.s_at_daniel.shahaf.name> wrote:
> 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,
exist in the DB but not on disk. The command I have in mind is 'svn up --set-depth=files fOO/'.
> but their parent dir is at depth empty (and let's assumed an unversioned 'foo' exists, too))).
>
I'm not implying that the truepath canonicalization should be removed entirely, it might make sense to do it somewhere further down the stack to still allow wrong-case target specification in cases where the wrong case is not ambiguous.
Received on 2011-04-23 11:13:56 CEST