[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Defining atomic "replace"

From: Bill Tutt <bill.tutt_at_gmail.com>
Date: Thu, 13 Aug 2009 10:41:30 -0400

On Tue, Aug 11, 2009 at 4:04 PM, Greg Stein <gstein_at_gmail.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. :)


Received on 2009-08-13 17:04:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.