merging trunk into a branch and back again

Henrik
Henrik
Are there any hidden dangers with merging trunk changesets into a branch, and then back into the trunk? I'm currently working on a firmware maintenance project in which we fix issues that continously emerge from our humungus user base. I've set up the repository with the ususal trunk, branches and tags directories. The workflow i'm planning to implement for our group is to solve each task in a separate branch and then merge the branch back into the trunk. The trunk is then run through a test suite and if deemed decent enough, it is released as a new version and a tag is created from it. The product owner, however, is well known for his late changes on which features/fixes he wants to release in a new firmware update so we will often end up not merging a task back into the trunk but just let it "hang around for later". When the trunk is updated, the users would want to merge the latest trunk changes into their "hangaround" branches, maby do some testing etc. When the task finally is scheduled for the next release they'd want to merge their branch into the trunk. If we have merged the latest trunk changes into the branch, will we be allright if we just merge the branch's changesets back into the trunk, or do we have to take the trunk->branch merges in to concideration? Any other strategy suggestions? regards, Henrik -determined but confused

Last updated

ginomarckx
ginomarckx
Sorry to answer this question this late. I started using subversion recently, hence the timing. You probably have the answer already, but I want to put it here just for the record. It is not a problem to merge back and forth changes between the trunk and a branch. You only have to keep some things in mind. Currently, Subversion has no notion of merge tracking, leaving the administration up to the user. If you are not careful and merge everything all the time, some changes will be merged more than necessary, resulting in an unwanted result. Let me explain this with a little example. Say that we have the trunk that we call trunk and a branch that we call... right... The branch started its life at revision 10, in the mean time, changes have been commited on both branch and trunk, and the head revision is 18. If we want to merge the changes on the trunk into the branch (I like to call these parent to child merges rebases, virtually creating a new branch, starting its life from the rebase point, so including all changes commited before that point), we just type the following: [code]svn merge -r 11:HEAD trunk branch[/code] After committing the changes we get revision 19. Now, if we want to merge the changes on branch back to trunk (which I like to call integrate), we need to do the following: [code]svn merge -r 11:18 branch trunk[/code] It is very important that we exclude revision 19 from the merge. Revision 19 is used to checkin the changes on the trunk since branch got its own life, independent from trunk, so merging revision 19 as well would duplicate all changes in trunk since the branch point. This action is commited in revision 20. Now, say that both branches are still used for development, and at a later stage, we want to do the same action. We then have to start merging from revision 21... Just another thing. Say that we got a conflict and need to do a manual merge for a specific file in the process... Since the result of the manual merge is committed in a revision that is excluded from the merge, when integrating, the manual merge must be done again... This is something to tackle in the future... Apparently there is no easy way to solve this problem, not even with a copy if you are sure that nothing changed on the trunk since the rebase...
ginomarckx
ginomarckx
If you are sure that nothing is committed on the trunk after a rebase, you can copy the conflicting files from branch to trunk with a normal file system copy and mark all conflicts as resolved.

1-3 of 3

Reply to this discussion

You cannot edit posts or make replies: You should be logged in before you can post.

Post a reply
9472 views