merges, joins, and changes Jonathan S. Shapiro (shap@eros-os.org)
Tue, 18 Apr 2000 12:01:34 -0400

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?