> 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).
Scenario two is called by many companies "re-baselining" and the
purpose of it is to avoid exactly what Ben metioned, removing any
changes made to the trunk while merging the branch back onto the
trunk.
IMHO a branch should always look like trunk + branch changes before a
merge. After all, your branch, if it is intended to ever be re-merged
onto the trunk, should be fully deployable so it can be tested. I
would consider scenario two to simply be good practice for any
software developer. At the company I work for a developer has to
rebaseline at least once a week to absorb both little things like bug
fixes and entirely new features written by coworkers simultaneously.
> 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.
I too find it hard in SVN to find where I have to merge from,
especially after a rebaseline. We are very heavily dependant on the
comments in the log for this but I don't think this is a problem
unique to subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 25 14:33:27 2004