On Sat, Apr 23, 2011 at 11:13 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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.
>
Hm, I'm not sure where it would go then. I don't know the layers quite
so well, so maybe I just don't see it. But it might be difficult to
find a good spot, "as late as possible", to do the truepath
canonicalization. If there is a good way to do this, it might be a
good long term solution to issue #3865 [1], but probably a lot of work
also ...
Then there is Brane's suggestion of just special-casing the commit,
which might just be good enough ...
2011/4/22 Branko Čibej <brane_at_e-reka.si>:
> Meh. For now, just hack a special case so that committing one half of a
> case-only rename will automagically commit the other half. Shouldn't be
> too hard to do, and it's almost impossible to do the wrong thing --
> after all, you're constrained by a) staying in the same directory, and
> b) both halves of a rename resolving to the same on-disk file on a
> case-insensitive file system.
Sounds like another option. A small change here and there to make
case-only renames work specifically (and not solve the more general
problem of fixing path-guessing via wc-db or truepaths).
The fact of the matter is that, for sane setups/companies,
case-clashes are going to be really rare, *except when doing case-only
renames*. A repository holding 'Foo', 'FOo' and 'FOO' would be a
repository that's un-checkoutable on a case-insensitive filesystem
anyway. So I'd expect companies that have to support case-insensitive
clients to keep real case-clashes out of their repository (or fix them
as soon as they are discovered).
So maybe "case-only rename" (and perhaps "case-only replace"
(delete+add w/o history)) is the only use-case we need to go for. But
apart from commit, we should maybe also make "revert" possible, as
well as adding to and removing from changelists ... (hm, commit would
be the main thing I guess, revert can always be done in two steps
(revert the add, then the delete), changelists ... oh well).
I'd love to hear some more input ...
Cheers,
--
Johan
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3865 ('svn' on
Windows cannot address scheduled-for-delete file, if another file
differing only in case is present on disk)
Received on 2011-04-25 01:09:14 CEST