On Sat, 23 Apr 2011 11:55 +0300, "Daniel Shahaf" <d...@daniel.shahaf.name> wrote: > On Fri, 22 Apr 2011 23:07 +0200, "Johan Corveleyn" <jcor...@gmail.com> 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 > > 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.