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
signature.asc
Description: This is a digitally signed message part.
