Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Re: Defining atomic "replace"

subversion
Discussion topic

Back to topic list

Re: Defining atomic "replace"

Author julianfoad
Full name Julian Foad
Date 2009-08-13 16:24:48 PDT
Message 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@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@3

The WC remembered that b.cs should be a copy of a.cs@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@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

« Previous message in topic | 15 of 22 | Next message in topic »

Messages

Show all messages in topic

Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-10 03:35:24 PDT
     Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-11 15:34:49 PDT
         Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-11 17:04:55 PDT
             Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-18 14:20:07 PDT
                 Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-19 10:53:47 PDT
                     Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-20 19:31:53 PDT
                         Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta stsp Stefan Sperling 2009-07-21 04:44:44 PDT
                             operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-21 06:36:04 PDT
                                 Re: operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta stsp Stefan Sperling 2009-07-21 07:44:55 PDT
                                     Re: operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta gavinbaumanis Gavin Baumanis 2009-07-21 16:33:05 PDT
                         Defining atomic "replace" [was: svn commit: r38394 - in trunk/subversion: include libsvn_delta] julianfoad Julian Foad 2009-07-28 03:28:37 PDT
                             Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-11 11:53:36 PDT
                                 Re: Defining atomic "replace" gstein Greg Stein 2009-08-11 13:04:12 PDT
                                     Re: Defining atomic "replace" Bill Tutt <bill dot tutt at gmail dot com> Bill Tutt <bill dot tutt at gmail dot com> 2009-08-13 07:41:32 PDT
                                         Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-13 16:24:48 PDT
                                             Re: Defining atomic "replace" Bill Tutt <bill dot tutt at gmail dot com> Bill Tutt <bill dot tutt at gmail dot com> 2009-08-14 11:12:04 PDT
                                 Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-11 16:27:08 PDT
                                     Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-11 16:31:17 PDT
                                     Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 10:51:43 PDT
                                     no-op-copy -- was: Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 12:00:55 PDT
                                         Re: no-op-copy -- was: Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-12 17:03:11 PDT
                                             Re: no-op-copy -- was: Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 17:53:07 PDT
Messages per page: