Monty's question caused me enough confusion that I'm going to try to clarify. Famous last words.. :-)
First, I use the terms "trunk" and "branch" only in a relative sense. Every branch begins as a clone of some pre-existing version of some other branch. To avoid confusion, it is convenient to refer to the parent branch as the trunk.
In actual fact, there *is* one trunk that is magic, which is the initial main trunk for a given project. This trunk is magic because it has no parent branch. You could imagine building some self-parented empty branch to terminate the upward recursion, but this is difficult when branches are named by their cryptographic hash.
> Why is the trunk special? That is, why prevent merges to the trunk but
not to
> branches?
Good question. Basically, it isn't.
Suppose that branch B is created from version 4 of a parent branch "trunk" (initially, B.1 = T.4). Development proceeds independently on both branches, arriving at B.3 and T.17.
At this point, you might imagine that the following operations should be supported:
The first operation reduces the drift between the two development paths. The second represents the integration of a (possibly continuing) set of changes from the branch back into the trunk. However, the second merge is wrong. The correct sequence for (2) is:
Merge the delta [T.17-T.4] into B.3, creating B.4 Integrate the delta [B.4-T.17] into T.17, creating T.18
This is one of those places where practicality may dictate supporting something that is in principle a bad idea.
That said, I can't think of any compelling case for allowing selective merge from the branch into the trunk. The only way you can need to do this is because you failed to create a branch at some point when you should have created one. My personal opinion is that a branch should be merged into its parent only as a consistent whole.
Hmm. I wonder if branch splitting is a useful idea here.
Somebody may come up with a compelling counter-argument, so I'm willing to be convinced.
> What if you branch a branch? Should you then not be able to merge files
into
> that branch, only entire branches?
Exactly. I would suggest that when you branch a branch the merges should be all or nothing. There is no possible way in principle that merging a subset of changes can result in a consistent cut. Every time you need to do that, it's because you failed at some point to create a branch.
The counterargument to this is: "yes, but people are human, and empirically they *do* fail to create branches."
In this case, perhaps the thing to do is create a new branch from the trunk after the fact, move the selected changes into that branch by hand, remove them from the previous branch, and merge the new branch instead. This is slightly painful, but it has the advantage that when you are done the merge history tends to better capture consistent changes.
> What advantage do you gain by recording merges as merges instead of normal
> changes?
The ability to merge again. Go back to my previous example. Suppose we do option (1), merging the delta [T.17-T.4] into B.3, creating B.4. Work now continues, creating (eventually) T.22 and B.71. At this point, we now wish again to merge the trunk evolution into the branch to reduce version drift. Unless we record that a previous merge occurred, we will wrongly attempt now to merge [T.22-T.4] into B.71. The correct merge is to merge [T.22-T.17] into B.71.
> I personally
> don't often encounter the situation where I know I want to blindly merge
this
> particular set of files or whole branch into the trunk or another branch
(but I
> don't build operating systems either ;-) ). But yes, I could just as
easily do
> the merging onto a branch as onto the trunk. That's about the only time
I'd
> really want to merge a whole branch to the trunk.
The working model for DCMS is that you always do development on a personal branch. When you are satisfied that the branch works, you do an integration (in case the trunk has moved), and then merge the entire branch back into the trunk.