Johan Corveleyn wrote on Mon, Apr 25, 2011 at 23:10:21 +0200:
> On Mon, Apr 25, 2011 at 5:03 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > Johan Corveleyn wrote on Mon, Apr 25, 2011 at 01:08:24 +0200:
> >> 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).
> >>
> >
> > Another use-case:
> >
> > When r1 contains a file 'Foo', r2 contains a file 'foo', the working
> > copy is at uniform revision r2, and the user types 'svn up -r1 Foo'.
> >
> > There is also a variant where Foo_at_r1 is a directory rather than a file,
> > but that's getting contrived.
>
> And I guess 'Foo' no longer exists in r2, and 'foo' didn't exist in
> r1? Maybe 'Foo' got renamed to 'foo'? Or maybe there is no historical
> relationship?
>
> Anyway, I think this also works right now, without any special tricks:
>
> - 'svn up -r1 Foo' gets canonicalized to 'svn up -r1 foo', the file
> on-disk, and currently present in the working copy.
>
> - If 'foo's ancestor is 'Foo', 'foo' gets deleted and 'Foo' is
> downloaded from the repository, by the update editor.
>
> The update editor currently has no problems with handling case-only
> renames on case-insensitive filesystems.
>
Sorry for not being clear.
In my example I intended 'foo' and 'Foo' to be two separate lines of
history.
% svnadmin create r1
% svn co file://`pwd`/r1 wc1
% cd wc1
% svn mkdir iota
% svn ci -m r1
% svn rm iota
% svn mkdir IOTA
% svn ci -m r2
% svn up -r2
% option #1: svn up -r1 iota
% option #2: svn up -r1 iota IOTA
For option #1, I specified 'iota', so I expect svn to error out saying
"You asked me to create ./iota but I can't because ./IOTA exists" (never
mind whether or not it's versioned).
Option #2 is what I'd expect to work to get me iota_at_1 (at the expense of
shifting IOTA_at_2 to not-present(?) state, but that's the best I can do
given the filesystem's limitations). It's probably a bit tricky unless
we can ensure the editor sends IOTA before iota, though...
> Cheers,
> --
> Johan
Received on 2011-04-25 23:27:39 CEST