[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] First step for issue #3702 (case-only renames on Windows) - now blocked by libsvn_client

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 21 Apr 2011 16:07:22 +0300

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>

> - 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.
Received on 2011-04-21 15:07:59 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.