You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ralf Haring <ra...@gmail.com> on 2010/06/10 01:58:06 UTC

merge and branch questions

Hi, I am relatively new to svn and had some questions about
maintaining branches and merging them back to the trunk.

The way my env is set up right now, ongoing development is done on the
trunk. We have branches corresponding to various releases along the
way. When needing to make a fix to an existing version, we've been
pretty bad about making the change on the trunk instead of on the
corresponding branch. We've in effect been treating the branches as
snapshots at the time of release only.

This kind of defeats one purpose of having the branches so we want to
do it right. I read the chapters at
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html
and http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
and want to see if I understand it properly. If I have a branch of the
latest release version, it seems that I cannot use the normal svn
merge to bring the change back into the trunk. As I understand it, svn
merge is for merging things into *branches*. To merge things back into
the trunk you would use the merge reintegrate option, but the branch
should not be used for future work thereafter. So how can I
periodically merge small fixes for the latest release back into the
development trunk?

I understand the use case of creating a branch for work on a specific
feature, keeping it up to date with normal dev changes as work on the
feature progresses, and finally udpating the trunk and ending the
branch. The workflow as outlined in the book fits that to a T, but it
doesn't seem to work so well for needing to keep a branch around for a
while and needing to do periodic merges to the trunk.

-Ralf

Re: merge and branch questions

Posted by Arpad Ilia <ia...@inf.u-szeged.hu>.
You can use 'svn merge' to merge changesets from the branch back into the trunk. You can also use reintegrate and still keep the branch, though it is not a very good idea since later trunk->branch 
synchronizations will cause lots of conflicts, as svn will try to merge the reintegration changeset into the branch. However this can be circumvented by doing a property merge (--record-only) for that 
changeset toward the branch and then doing the trunk -> branch sycnhronization as usual.

Nevertheless, I would recommend creating a new branch after every reintegrate as the book says.

Arpad Ilia

On Thursday, June 10, 2010 03:58:06 am Ralf Haring wrote:
> Hi, I am relatively new to svn and had some questions about
> maintaining branches and merging them back to the trunk.
> 
> The way my env is set up right now, ongoing development is done on the
> trunk. We have branches corresponding to various releases along the
> way. When needing to make a fix to an existing version, we've been
> pretty bad about making the change on the trunk instead of on the
> corresponding branch. We've in effect been treating the branches as
> snapshots at the time of release only.
> 
> This kind of defeats one purpose of having the branches so we want to
> do it right. I read the chapters at
> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html
> and http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
> and want to see if I understand it properly. If I have a branch of the
> latest release version, it seems that I cannot use the normal svn
> merge to bring the change back into the trunk. As I understand it, svn
> merge is for merging things into *branches*. To merge things back into
> the trunk you would use the merge reintegrate option, but the branch
> should not be used for future work thereafter. So how can I
> periodically merge small fixes for the latest release back into the
> development trunk?
> 
> I understand the use case of creating a branch for work on a specific
> feature, keeping it up to date with normal dev changes as work on the
> feature progresses, and finally udpating the trunk and ending the
> branch. The workflow as outlined in the book fits that to a T, but it
> doesn't seem to work so well for needing to keep a branch around for a
> while and needing to do periodic merges to the trunk.
> 
> -Ralf