> (*) 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.
There are LOTS of APIs in our system that do not understand moves. The
> 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.
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
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:
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. :)