2

I have read a lot and lot on this but couldn't figure out what the issue is, and it's pretty weird. I am using version 1.7 for server and latest tortoise version (1.7) for the client. Here's the scenario:

  1. I created a parent branch, and then created 1 child branch from it. So, PARENT_BRANCH -> CHILD_BRANCH
  2. Add a new directory in CHILD_BRANCH and commit.
  3. Using tortoise merge all changes from CHILD_BRANCH to PARENT_BRANCH. I used 'merge a range of revisions' option and didn't specify any revisions in the option, so basically let svn identify and manage the revisions to merge.
  4. After the merge, the new directory is created in PARENT_BRANCH.
  5. Merge back from PARENT_BRANCH -> CHILD_BRANCH.
  6. I get tree conflict on the new directory, with the error that the directory its trying to add is already there.

Well, of course the directory is there in child branch as that's where it originally came from. I though that svn 1.5+ tracks merges using merge-info, and should have known this is the branch from where the directory came and should not throw the tree merge error.

Any idea what's going on and how can I fix this? The example I gave is just for 1 directory, but in reality there are lots of directories and files, so going one by one manually takes hours.

kmote
  • 16,095
  • 11
  • 68
  • 91
AC1
  • 463
  • 3
  • 9

2 Answers2

6

The problem is that both CHILD and PARENT have different revisions which added the same folder. CHILD doesn't have any knowledge of the revision in your step 4.

Immediately after every merge from CHILD to PARENT (your step 4.) you need to record against CHILD that it has the revision of the merge from CHILD to PARENT. You do this by merging that revision in PARENT to CHILD and checking this flag in tortoisesvn:

enter image description here

Have a read of this post on subversion branch reintegration.

Community
  • 1
  • 1
mounds
  • 1,303
  • 12
  • 11
  • Thanks for the response. So if I understand it correctly, if let's say while merging from CHILD->PARENT, svn identifies r100-r200 will be taken and merged from CHILD. Post merge, when I commit, lets say it was revision r201. So, now I have to tell CHILD to record r201 as "record only" so that when I merge back from PARENT->CHILD, this particular revision will be ignored and I should not get any tree conflicts arising because of CHILD->PARENT->CHILD merge. It's really strange, since svn should know that already as to which branch originated the create directory command in the first place. – AC1 May 06 '13 at 06:18
  • No worries, yes what you describe is correct. Since svn doesnt record against the "mergee" the details of where it has been merged to and the revisions made when the merge was committed, it can't do what you want. Svn certainly works better for short lived feature branches than long term branches like what you are using. – mounds May 06 '13 at 09:25
2

SVN is a tool that can be used in a lot of different ways. Some use cases are well supported and others are not. Merging in both directions continuously between two branches belongs to the latter category.

For this reason, SVN is not suitable for all projects. However, it works quite well for most projects, because there is no need to merge changes in both directions. The typical workflow with SVN is as follows:

A feature branch is created, changes are made to the feature branch and all changes from the originating branch are merged to the feature branch, so that the feature branch contains everything from the originating branch plus some additional features that only exist on this particular feature branch. As soon as the feature branch is complete, it is reintegrated with the originating branch, and closed.

This workflow is well supported by SVN and works quite good in most projects.

nosid
  • 48,932
  • 13
  • 112
  • 139
  • Thanks for the response. I can't use reintegration since this branch will not go away. It's a regular development branch, where we add features, push it out to production, and then continue working on it for the next release. – AC1 May 06 '13 at 06:06
  • @AC1: Please explain in which situations you have to merge changes in both directions. It's difficult to help you without understanding your actual requirements. – nosid May 06 '13 at 07:01
  • sure. Our branching structure is like this. We have a 'trunk' branch (PARENT), and there are multiple CHILD branches, like 'shortterm', 'longterm' (am making the names up to give you the idea). Developers keep working in these branches in small 2 week sprints for shortterm and 8 week sprints for longterm. Once the sprint is completed, the branches merge their changes into trunk, trunk is pushed to production, and then trunk is merged back to shortterm and longterm so they both can be in sync. The child branches live forever and don't cease to exist after a release to production is done – AC1 May 06 '13 at 17:13
  • @AC1: There is nothing special with your workflows. Changes are only merged from trunk to development (feature) branches, and the feature branches are reintegrated with the trunk after each sprint. Usually, you would delete the branch at the end of the sprint and create a new branch for the new sprint. However, it is also possible to reuse the existing feature branch. The section [Keeping a Reintegrated Branch Alive](http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice) in the book _Version Control with Subversion_ explains how that works. – nosid May 06 '13 at 18:45
  • Thanks nosid. I think that's exactly what @mounds also mentioned in his response. Thanks to both of you for making me understand this. – AC1 May 06 '13 at 21:39