On Thu, 2009-08-13, Bill Tutt wrote:
> Move, you mentioned move. You're giving me a headache flashback.
Hi Bill. Thanks for the thought input...
> i.e. The directory heirarchy changing dependant case:
> A\a.cs A\B\C\c.cs
>
> mv A\B B
> mv A B\A
>
> This ends up with B\A\a.cs and B\C\c.cs.
>
> Regardless of whether not you can submit such a thing in one
> changeset, a non-operational merge would need to deal with the
> problem. (i.e. not allowing it in the general changeset case doesn't
> prevent it from the non-operational merge case)
Yes, OK...
> or the substantially less annoying and fairly simple dependant rename
> case:
>
> mv a.cs temp.cs
> mv b.cs a.cs
> mv temp.cs b.cs
which swaps a.cs with b.cs, and is equivalent to (and let's say the
current revision is 3)
del a.cs
del b.cs
copy <URL of a.cs>@3 b.cs
copy <URL of b.cs>@3 a.cs
> Both of the above cases also suffer from the problem of needing to
> disallow not including all of the pending moves in a submission.
<parsing double-negatives>... <done>
In Subversion, currently, as you know, you are allowed to commit just
one half of the moves. Let's examine what happens if you do. Note that
the selection of what to include in the commit is done by path, not by
"object identity". If in your latter case we choose to commit just
"a.cs", the result would be:
r4:
a.cs is replaced with a copy of b.cs_at_3
b.cs is unaffected
I agree that there is a usability benefit in disallowing this partial
commit, but I don't see that it causes any particularly bad or
surprising result. You can still commit the other half (b.cs) later and
get the intended end result:
r5:
a.cs is unaffected
b.cs is replaced with a copy of a.cs_at_3
The WC remembered that b.cs should be a copy of a.cs_at_3. If instead it
had remembered it as "a copy of head revision of a.cs", this second
commit would be effectively a no-op because a.cs_at_HEAD was at this time
already the same as b.cs, and that would not be the intended end result.
As part of "true renames" support, we will probably want to change the
semantics of moves and copies to say "a copy of head revision of ..."
rather than a specific revision number. Then we will have to watch out
for this split commit, and probably disallow it.
> (Esp. of directories, but disallowing it entirely always seemed like a
> good idea to me.) If you allow partial pending move submissions then
> you're submitting a tree state you haven't built yet.
Yes, but that's true of any kind of partial commit where you make WC
modifications in one order and then commit the pieces in another order.
You feel this is particularly bad in the case of splitting a move. I
think we all agree it's worse and not a good idea, but I don't
understand whether you have some special viewpoint that makes you feel
it's so terrible or such a headache.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383472
Received on 2009-08-14 01:26:44 CEST