I've browsed through most threads discussing the repeated merge problem -
and kind of I fear it. I simply can't figure out if this limitation will
cause trouble for us. I'd like to make use of branches in the following way
(it's very "ClearCasish", and suggestion on workflows that suit svn better
are wellcome...):
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.
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>
Will this approach work smoothly if we don't start merge changes directly
between the branches, or have I missed something important?
Henrik
---------------------------------------------------------------------
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:28:26 2003