On Mon, Apr 25, 2011 at 11:26 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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).
I'm confused. If you type "svn up -r1 iota", the iota is a target of
the PATH variety, or in any case you're trying to address something in
the working copy. At this point there is no ambiguity: you're actually
referring to IOTA (the on-disk truepath), because what else is there
(there is no iota present on disk, nor in the wc metadata)?
So you're really asking to update IOTA to r1, in which it didn't
exist. So this is a perfectly valid operation, which would result the
deletion of IOTA (and nothing else).
> 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...
No, this is identical to option #1, I think. There is no iota on-disk,
nor is there in wc-metadata, so you can only be referring two times to
IOTA.
--
Johan
Received on 2011-05-03 21:50:36 CEST