On Tue, Jul 21, 2009 at 04:30:53AM +0200, Neels Janosch Hofmeyr wrote:
> - is it ok to disallow multiple add() and delete() calls on the same path,
> in principle?
> e.g. during merge, there are only the two sides, merge-left
> and merge-right. A replace means that both exist but are "unrelated". So
> a merge will never need to send more than one (delete, add) tuple.
> Usually it's either *one* delete or *one* add. The (add, delete) tuple
> simply cancels out, nothing being sent.
>
> But are there cases where we also send all the steps in-between? Then we
> could allow this: add(), add(REPLACES_REV), add(REPLACES_REV), delete().
> But *are there*?
>
> - is it necessary to disallow multiple add() and delete() calls on the same
> path, to make the atomic replace useful?
> e.g. during merge, the receiver needs to cache all delete()s and match
> with add()s, carrying out the leftovers during dir_close(). And merge
> is not the only one in need of this quirky code construct.
> I want to eradicate this madness -- I'd love to force atomic replaces
> on everyone, so the receivers are entirely relieved of this quirkiness.
> Will allowing both separate and atomic replace calls defy my plan by
> actually adding more code to the receivers?
>
> - is there a case where separate calls have a different meaning than an
> atomic replace?
> e.g. for merge, it doesn't matter whether the nodes are "related".
> I can't think of any case where we'd want to highlight that the node was
> deleted and later re-added with the same history, or something. Right?
>
> ~Neels
Note that if we ever switch to operation-based merging, a sender
might send mulitple replace calls for the same item.
Right now, Subversion just looks at the static difference between
the source and target branches, and tries to eliminate this difference.
Operation-based merging adds a notion of time to this difference.
It means that tree operations such as copy, delete, add, replace
would be replayed in order on the target branch just like they
happened on the source branch in the revision range being merged.
This would make handling tree conflicts much easier, and would also
deal with other wrinkles, such as the fact that copies aren't being
merged from one branch to another in a useful way.[*]
The editor interface should allow for this kind of operation.
In the long term, I hope to see Subversion do operation-based merging.
Stefan
[*] We end up merging "svn copy /branch/A /branch/B" from branch
to trunk as "svn copy /branch/B /trunk/B" while it should be
"svn copy /trunk/A /trunk/B" plus merging any additional textual edits
made in /branch/B since its inception into /trunk/B.
Right now, edits made to /trunk/A after branching do not make their
way into /trunk/B in the merge result, which is wrong since B is
supposed to be a copy of A on trunk, too, but ends up not being a copy
of /trunk/A. And it's even worse with moves because changes made to A
after branching just get dropped in <1.6. In 1.6 and beyond, we're
flagging a tree conflict on A, (local edit, incoming delete upon merge)
but we should be handling this automatically. And IIRC detecting this
case doesn't even work for directories right now.
Received on 2009-07-21 13:45:03 CEST