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 Bill Tutt <bill dot tutt at gmail dot com>
Full name Bill Tutt <bill dot tutt at gmail dot com>
Date 2009-08-13 07:41:32 PDT
Message On Tue, Aug 11, 2009 at 4:04 PM, Greg Stein <gstein at gmail dot com> wrote:

> > (*) Atomic move > In the new editor callbacks, there is a separate
> move() call to represent
> > atomic moves. It is thus possible to issue a delete() followed by a
> move()
> > to the same path that was deleted. Which is, essentially, a replace!
> >
> > --> We need to also add a REPLACES_REV argument to the move() callback,
> and
> > we need to disallow issuing a delete followed by a move to the same path.
>
> Agreed.
> > Actually, has this case ever been considered? Currently, a move()
> becomes an
> > "add-with-history" plus a delete(). Our API doesn't indicate a move
> > replacing a path. We could need another update/status letter for this.
>
>
> There are LOTS of APIs in our system that do not understand moves. The new
> wc_db can record moves, but (in 1.7) nothing is going to *tell* it
> to do that. This new editor API can describe moves, but nothing will
> drive it that way. Or maybe it will, and the receiver will break it
> down to a delete/add to deal with legacy APIs that do not have a move
> operation.
>
> I expect that, over time, we will start propagating a "move" concept
> further and further through our codebase. Only at legacy points (eg.
> speaking to an old server) will they be broken into a delete/add pair.
>

Apologies for the slightly off topic direction shift:
Move, you mentioned move. You're giving me a headache flashback.

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)

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

Both of the above cases also suffer from the problem of needing to disallow
not including all of the pending moves in a submission.
(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.

Ugh. Ok, the headache flashback is over now, back to your normal subversion
work. :)

Bill
Attachments

« Previous message in topic | 14 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: