3

If two developers each create a feature branch from trunk, is it safe for them to "sync merge" between their feature branches as well as from trunk, and then still be able to reintegrate each feature branch to trunk without issue?

By "sync merge" I mean a command of the form "svn merge ^/Project1/trunk" and "svn merge ^/Project1/branches/other-feature-branch" where the svn:mergeinfo property will keep track of what has been merged already from each location.

The reason I ask is that I've read documentation in a number of places that suggests that remerging in the same revisions to a branch will cause conflict problems (although I don't see anywhere where it is explained why this should be the case). If this is so then the scenario described above should be problematic because each feature branch will be syncing with trunk as well as with the other feature branch, therefore any changes made in trunk will be recieved both by syncing with trunk directly but also when syncing with the other feature branch (which may have picked up the same trunk changes already).

However in the testing I've done this appears to work perfectly well, but I'd like some expert reassurance before I recommend this as a workflow for our team.

@nosid: Replying to nosid in this edit because the ridiculous character limit on SO prevents a 4 sentence comment. What is this Twitter?

I've read the documentation. The problem is it describes a very simple scenario where only one destabilizing feature is worked on at a time, and where the destabilizing work is done in a feature branch while all the other work is done in trunk. In that scenario it's trivial to keep the feature branch in sync with trunk.

However in a more realistic scenario a product can quite easily be having several major destabilizing pieces of work done on it at once. What then is the process for keeping those pieces of work in sync in such a way that they can sync on demand with trunk and each other but without having breaking changes forced upon them?

Neutrino
  • 8,496
  • 4
  • 57
  • 83
  • You can have an arbitrary number of feature branches at the same time. That's no problem. The changes on each branch can also be huge - as long as the overlap is small. It doesn't work if the overlap is huge, but I would try to avoid instead of _cross-merging_. – nosid Apr 08 '12 at 12:30

3 Answers3

4

This is not the way, feature branches should be used in Subversion. A test with a simple example shows, that this approach will cause problems later. Try the following steps:

  • Create a new repository.
  • Create and commit the initial structure (trunk, branches, tags).
  • Create and commit two new branches of the (empty) trunk with svn cp -m 'new branch' ^/trunk ^/branches/a and the corresponding command for ^/branches/b.
  • Add and commit a new file on branch b.
  • Merge the changes from branch b to branch a with svn merge ^/branches/b. I have made no changes on the trunk, so there is nothing to be merged.
  • Reintegrate and commit branch a on the trunk with svn merge --reintegrate ^/branches/a.
  • Merge the changes from the trunk to branch b with svn merge ^/trunk.
  • Now, you will see a tree conflict on the file you have added earlier.

The documentation of Subversion explains the recommended usage of feature branches in detail. See the following link: Feature Branches. A feature branch is usually created from the trunk. You make your own changes on the feature branch and continuously merge the changes from the trunk into your feature branch (with svn merge ^/trunk). And as soon as you have finished your work, you reintegrate the branch into the trunk (with svn merge --reintegrate ^/branches/name). After reintegration, the feature branch is obsolete and should not be used anymore.

nosid
  • 48,932
  • 13
  • 112
  • 139
  • Yes I see, that is indeed a bummer. My testing was too simplistic, I was only testing changes to existing files rather than the addition of new ones so I didn't hit this snag. – Neutrino Apr 05 '12 at 11:05
  • Since SVN 1.8 the --reintegrate switch is no longer needed - you just do a regular merge and SVN does all the magic needed not to produce a tree conflict. Have a look here: http://stackoverflow.com/questions/18444634/tortoisesvn-subversion-1-8-merge-no-more-reintegrate-a-branch-option – knee-cola Dec 14 '16 at 14:37
0

Here's my take on the OP's question. You may notice some parallels with the testing steps suggested by other sources for determining the answer to the question, but I come to a different conclusion.

Here's my repro script:

#----------------------------------------------------------------------
# Test whether merging between feature branches in SVN results in
# tree conflicts, as claimed elsewhere:
#   http://stackoverflow.com/questions/10015249
#----------------------------------------------------------------------
export REPO=file:///tmp/merge-test/repo

#----------------------------------------------------------------------
# Create a new repository.
#----------------------------------------------------------------------
echo Creating a new repository ...
cd /tmp
rm -rf merge-test
mkdir merge-test
cd merge-test
svnadmin create repo

#----------------------------------------------------------------------
# Create and commit the initial structure (trunk, branches, tags).
#----------------------------------------------------------------------
echo Creating initial structure ...
svn mkdir $REPO/trunk -m "Initializing trunk"
svn mkdir $REPO/branches -m "Initializing branches"
svn mkdir $REPO/tags -m "Initializing tags"

#----------------------------------------------------------------------
# Create and commit two new branches of the (empty) trunk.
#----------------------------------------------------------------------
echo Creating two new branches of the empty trunk ...
svn cp $REPO/trunk $REPO/branches/a -m "branch a"
svn cp $REPO/trunk $REPO/branches/b -m "branch b"
svn co $REPO/trunk
svn co $REPO/branches/a
svn co $REPO/branches/b

#----------------------------------------------------------------------
# Add and commit a new file on branch b.
#----------------------------------------------------------------------
echo Adding and committing a new file on branch b ...
cd b
echo testing > foo
svn add foo
svn ci -m "committing new file"

#----------------------------------------------------------------------
# Merge the changes from branch b to branch a.
#----------------------------------------------------------------------
echo Merging the changes from branch b to branch a ...
cd ../a
svn merge ^/branches/b
svn commit -m "merged b into a"

#----------------------------------------------------------------------
# Reintegrate and commit branch a on the trunk.
#----------------------------------------------------------------------
echo Reintegrating and committing branch a back to the trunk ...
cd ../trunk
svn merge --reintegrate ^/branches/a
svn ci -m "merged a back into trunk"

#----------------------------------------------------------------------
# Merge the changes from the trunk to branch b.
#----------------------------------------------------------------------
echo Merging the changes from the trunk to branch b ...
cd ../b
svn up
svn merge ^/trunk
svn ci -m "refreshing b from trunk"

#----------------------------------------------------------------------
# Look for a tree conflict on the file added earlier.
#----------------------------------------------------------------------
echo Looking for tree conflicts for the file added earlier ...
svn status

There is no output from the last (svn status) command, which presumably means there are no tree conflicts. As far as I can tell, there is no explicit statement in http://svnbook.red-bean.com/ indicating that merging between branches would cause problems (beyond the normal conflicts that any merge can encounter, including merging between a branch and trunk). If anyone has evidence that cross-branch merging is any more problematic than merging in general, I'd be very interested in examining that evidence. Until then, I'm inclined to advise the OP that there's nothing inherently dangerous in the practice.

Bob Kline
  • 304
  • 1
  • 14
  • This is very strange. I worked through your example line by line and did get a tree conflict at the step "Merge the changes from the trunk to branch b" svn output was "svn merge ^^/trunk --- Merging r5 through r8 into '.': C foo.txt U . --- Recording mergeinfo for merge of r5 through r8 into '.': G . Summary of conflicts: Tree conflicts: 1" That's with svn version 1.7.8 – Neutrino Nov 20 '15 at 11:25
  • I know that svn 1.7 is a couple of versions old now but upgrading to 1.9 causes any attempt to checkout a large repository from a 1.7 server to fail with a client exception on Windows, so I'm suck with 1.7 until we upgrade the server. – Neutrino Nov 20 '15 at 11:28
-1

If you'll be syncing both feature branches with each other, what's the point of having two?

They'll essentially be the same.

Edson Medina
  • 9,862
  • 3
  • 40
  • 51