Henrik.Viklund@hotswap.se writes:
> We would use a folder "trunk" as "main branch". Whenever we want to
> implement a new feature to the system we'll make a branch by copying "trunk"
> to some other location in the repository. After a while people will start to
> merge their completed features from their dedicated branch into "trunk". The
> next feature is developed in another branch.
>
> Now, the people still working on the other features will want to update
> their branch with the latest changes of "trunk". They'll continue to
> periodically update their branch with changes from "trunk". When they're
> finally done coding the feature in their branch, they'll too will merge the
> new feature into the trunk.
Yes, you understand correctly. The Subversion project itself uses
this strategy from time to time -- in particular, whenever someone is
developing a feature that
1. takes a very long time
2. requires many commits (which should be reviewed incrementally)
3. could disrupt the stability of /trunk
If you look in the /branches directory of our own repository, you'll
see our long-running feature branches.
I know that Clearcase *requires* that you create a personal branch
before creating every single change, but you don't really need that
kind of fanaticism with CVS or Subversion. Remember that a CVS or
Subversion working copy *is* a personal branch of /trunk. When you
'svn up', you're receiving the latest changes from /trunk, when you
'svn commit', you're pushing changes into /trunk.
Keep in mind that most changes are simple things: they can be done
quickly, in a single reviewable commit, and won't disrupt /trunk. So
it's usually not worth creating and destroying branches for every
single change. That's why we have working copies.
> If i've understood this merge-discussion, i'll be home safe if I remember
> the revision number that I used for the last merge into this particular
> branch? I then merge the revisions higher than that in into my working copy
> of the branch, and so on:
>
> svn merge -r 23:30 <trunkpath>
> <something nice has happened to the "trunk" so i want to update my branch>
> svn merge -r 31:39 <trunkpath>
Yes, this is exactly what we do.
Remembering this stuff isn't a nightmare. If you run 'svn log -v' on
the branch, you can rediscover the revision in which the branch was
created: just look for the copy information.
And whenever you commit local mods created by a merge, make sure your
log message is descriptive: "Merging changes r23:30 from /trunk into
/branches/foo." That way, 'svn log branch' will always remind you
what you've merged already.
The repeated merge problem isn't a showstopper by any means: it's
just that it would be *nicer* if 'svn merge' automatically remembered
this stuff for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 17 14:42:22 2003