"Ben Collins-Sussman" <sussman@collab.net> wrote
> This scenario works only if you know that all changes in the trunk are
> already in the branch, because in the end, you're effectively converting
> the trunk into a perfect copy of the branch! If the trunk contains
> *any* change that isn't in the branch, then that change will be
> *removed* when you run a merge command that compares the tips of both
> branches.
Yes, that's very true. And I was careful to keep track of that properly.
That's certainly where the future merge tracking features would come in very
handy.
>
> That scenario doesn't seem so common to me; after all, most lines of
> development truly diverge in different directions. In the scenario you
> describe, you're going through very specific measures to guarantee that
> the branch is always a strict "superset" of the trunk. I've never seen
> any other group live by such a strict policy. Maybe I've not seen
> enough of the world. :-)
"superset" would not be an applicable word in my case, because I removed
many files, moved a lot more others, added a lot, and changed a whole bunch.
I would characterize my branching choice as "I need to change a lot of
stuff, and I want to be checkpointing it into source control along the way,
but I don't want to mess other people up until I'm done, so I'll do it in a
branch and merge it into the trunk later." I suspect that that is a very
common scenario, perhaps the most common reason for creating
developer-specific branches.
Now, a developer faces two choices when doing that.
1) Make a copy of the trunk at revision X, work on it for some amount of
time (while trunk is undergoing separate development), then merge the
changes from X-HEAD in the branch back into a trunk work area, check that
they merge fine, test it all, then commit.
That's the scenario envisioned in the Subversion book. I suggest that it
works well when someone is doing a small localized change. However, I don't
think it's very scalable. For instance, if I jump right to a very stretched
out unrealistic situation, suppose this branch was made a revision 100, and
work was done on it for 2 years. The trunk has undergone 5000 revisions, the
branch 1000, and now we're ready to merge. It's unlikely that merging the
changes from 100-6100 of the branch into trunk will provide something
useful, assuming that trunk and branch have undergone a healthy amount of
refactoring over time. Furthermore, that's 2 years that someone has been
been making changes to something that is increasingly unlike the trunk and
probably bears no resemblance to it in the end.
Now, that's a ridiculous time frame, but drop the time frame down to 1
month, and you have the actual scenario I faced and that many developers
face routinely.
In this scenario, the branch always looks like (trunk + branch changes -
trunk changes since the branch was made). Any testing done in the branch is
therefore highly suspect, since the code doesn't represent a state that will
ever be released.
2) Make a copy of the trunk at revision 100 (for illustrative purposes), and
start working on the branch. Periodically, merge the changes from the trunk
into the branch. Say 2 days later the repository is at revision 130. Merge
100-130 of trunk into the branch. This now makes it *as though* the branch
was copied from revision 130. Three days later, merge 130-150 into the
branch. Another 2 days later, when ready to re-merge, merge 150-HEAD from
the trunk into the branch. Then, merge the HEAD of branch to the head of the
trunk (making sure, of course, that someone hasn't snuck in another change).
That has the distinct advantage of keeping the branch looking at all
times like (trunk + the branch changes). It is a potentially deployable set
of code at all times, making testing more meaningful.
This strategy also reduces the merges to small, manageable chunks that
tend to have fewer conflicts. I found this to be painless as a daily
activity keeping my branch in sync with the latest changes in the PVCS trunk
I was dealing with.
The downsides are that you have to keep track of the incremental merges
from trunk that you have done and need to make sure that they are
continuous. Scripting can help this significantly, and the future merge
tracking should remove this as a source of pain.
Another more subtle downside is that changes merged in from trunk to the
branch will cause the branch's space in the BDB backend to grow
significantly, even for files that haven't otherwise been changed in the
branch. To Subversion, the merge from trunk *looks like* changes made in a
trunk work area, so the full contents of the files get stored in the branch.
I assume that the FSFS doesn't have this problem as much given the way it
stored deltas.
Patrick Rusk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 24 22:48:32 2004