I would recommend that you take a look at the PRCS merge algorithm (in the reference manual). The algorithm operates on a DAG of project versions, so it doesn't pay any attention to what versions are on what branches. It has some flaws that stem from the fact that its algorithms always operate on three versions (working, selected, common ancestor) and that it doesn't retain path properties such as "the user chose not to add file 'F' two merges ago" and so it will repeat the question "would you like to add 'F'?" at every merge between the same branches. I'm moving towards keeping a complete undo/redo log of all operations.
-josh
Quoting Jonathan S. Shapiro (shap@eros-os.org):
> Okay. I've obviously generated just plenty of confusion. Actually, this is
> good, because it means that I'm not a total idiot and the answers really
> weren't obvious. I now think that I understand why.
>
> It may help to understand how this confusion all got started.
>
> In CVS, your working area isn't a branch. This is part of why you can't do a
> local commit in it. It really captures exactly one layer of changes relative
> to some existing branch. Ignoring JCR's provocative (and useful)
> perversities, the behavior is that the working area always gets checked back
> into the branch.
>
> A side effect of performing a cvs update is that the "baseline" of a
> modified file may move forward. If you did a "cvs checkout" of trunk.14, CVS
> remembers that your changes are relative to trunk.14. Suppose that the
> branch meanwhile advances to trunk.17. After your next "cvs update", CVS
> will remember that your changes are now relative to trunk.17.
>
> In DCMS, the goal is for all work to be done done relative to a private
> working branch. Because of this, the implementation of CVS update becomes
> trickier. It is no longer sufficient to remember baselines in the working
> area. We must now also remember baselines in the branch itself.
>
> There are two approaches one might adopt to doing this:
>
> 1. Make "cvs update" be an operation between a branch and it's parent.
> 2. Close out the current working branch, create a new branch based on the
> current trunk version (in this case, trunk.17), apply the deltas to carry
> your changes forward onto this new branch, and make a note that the previous
> working branch was supersceded by this one.
>
> Unfortunately, option (2) breaks sub-sub-branches.
>
> As long as we can think of commits on the working branches as nested
> transactions, everything is okay. This is assured if working branches are
> strictly nested (which is what JCR didn't like). The minute the transactions
> are not nested we can no longer implement cvs update in a way that behaves
> clearly.
>
> A great deal of what I want here could be accomplished by simply keeping
> some form of undo log in my work area locally. The only thing that this
> would *not* accomplish is nested work areas. I don't find that I need these
> very often.
>
> Perhaps I shouldn't be thinking of these as branches at all, but they seem
> to differ from ordinary branches only in the hierarchy restriction.
>
> Insights, anyone?
>