Carl Lerche writes:
> Hello all,
> I had a hopefully simple question. Let's say I have a big project to
> work on, and I create a branch of trunk. The project will take a few
> weeks and I want to also keep the branch up to date with trunk. So,
> every end of day, I merge from trunk into the branch. As far as I
> understand, the command would be something similar to this:
> svn merge -r r1:HEAD http://svn.foo.com/project/trunk
> where r1 is the last time (the day before) that I integrated from trunk.
> My question is this, is there an easier way to keep track of what r1
> is than to go through log messages? It seems that it would be
> somewhat of a pain.
> Thanks for any help.
A basic rule for branches is to tag the code the branch is based on.
The following supports branching (I use scripts which handle the
Creating branch "mybranch" and checking out to "branch-workspace":
svn copy trunk tags/mybranch/base
svn copy tags/mybranch/base branches/mybranch
svn checkout branches/mybranch branch-workspace
At this point you have a branch plus a tag recording the code the
branch is based off of.
To merge the trunk to the branch (first commit branch changes):
svn copy trunk tags/mybranch/new
svn merge tags/mybranch/base tags/mybranch/new
When you determine the merge is good (so want to commit the result):
svn commit -m "Commit merge"
svn delete tags/mybranch/base
svn move tags/mybranch/new tags/mybranch/base
This makes "base" the code you're now based on after the commit.
To merge the branch back into the trunk, you now have a simple way to
do the merge. First commit in all branch changes then do:
svn merge tags/mybranch/base branches/mybranch
You now have a new trunk workspace with your branch changes.
Finding out what you've changed in a branch is also simple:
svn diff tags/mybranch/base branches/mybranch
Using a scheme like this, you almost never need to worry about
revision numbers. The only time I've dealt with revision numbers
lately is resurrecting a deleted branch (because I haven't had a
reason to automate it).
I use scripts to automate the above. One flaw is that a failure in
the middle of a sequence will need to be manually repaired, but that
should be infrequent. A tool like mucc could make these operations
atomic since mucc performs multiple SVN commit, copy, delete, etc
actions as a single change.
Another approach is used by the tool svnmerge, which uses properties
to track revision numbers and gives you find grained merging between a
branch and trunk.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Feb 8 19:26:41 2007