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
Received on 2010-06-10 09:41:14 CEST