How do I determine if svn:mergeinfo is corrupt and how would I fix it?

Question

I suspect I have corrupt mergeinfo but I'm not sure. Does anyone know how I'd make a determination and what resources are out there to help fix problems?

Here’s the issue. My team recently moved to agile and uses feature branches (story branches really) where different teams work on the same sources concurrently. As the story achieves a high state of readiness the team merges to trunk. The merges are taking days or weeks due to missing changes, unexpected changes, and conflicts. We are talking about teams of 5-10 people and the effort/churn seems way to high.

People use the this merge pattern a) PULL - merge trunk-to-branch, resolve, test, commit b) PUSH - merge branch-to-trunk, resolve, test, commit c) Recreate branch (or usually create new story branch and drop old since it's done)

By the end of this the branch and trunk should be in alignment.

Problems we are seeing:

1. changes not reported during trunk-to-branch merge show up in subsequent branch-to-trunk
2. conflicts on svn:mergeinfo properties during merge
3. file missing, but local edit on new file added in branch and pushed to trunk
4. incoming + local delete (file deleted on trunk and branch shows as conflict)

(1) Should not be happening. The pull from branch to trunk should put the two in sync for all changes already on trunk. The changes in branch-to-trunk merge are changes that happened on the trunk. So in the first merge they should have propagated to branch but didn’t. This points to corruption in mergeinfo data which would “hide” trunk changes.

(2) Should not be happening. SVN should be managing the changes in the merge tracking. This also points to corruption in the mergeinfo data

(3) Should not be happening. This is a case of a new file added on branch. It should show up as a new file added to trunk. This also points to corruption in the merge info data.

(4) I believe this is a SVN bug and that we can’t fix this. Still if this were our only problem I'd be happy

We are currently on svn 1.5.x server with clients using svn 1.6.x and svn+ssh for connecting. We plan to go up to the latest and greatest SVN since some fixes may impact our problems.

Still, it sure looks like our mergeinfo data is wrong.

• Merges that don't report all changes
• Conflicts in merge of mergeinfo properties

Any good places for me to start looking?

Confection

SVN 1.6.11 client may be my answer. I used the wandisco upgrade site (which rocks) and the merge hell is much less hellacious – Confection

Are you using the "--reintegrate" flag for the "push" merge? The fact that you have a "resolve" step after it suggests to me you aren't. I can't find specific documentation saying two-way merges without "--reintegrate" can't work, but the very existence of "--reintegrate" suggests svn's merging is otherwise not up to the task. – Tristatristam

Answer 1

I did some experiments with SVN branching/merging, and I found out that there are some situations when the merging just doesn't work - for example changes from trunk are overwritten. So if you keep using SVN for feature branches, you'll be in world of pain.

I made similar experiments with git and I haven't found a way to get incorrect merge. If moving to git might be acceptable by team/management, I strongly recommend using it.

Clergyman

I hear that, but that the conflicts on mergeinfo properties seems to indicate a deeper problem – Confection

I think I should get myself clearer: I tried to break merge in SVN and I succeeded on my second attempt, but I wasn't able to create corrupted/incorrect merge in Git. So you can try to track root cause of mergeinfo problems, or you can use your time more effectively and switch to more branch-friendly version control system. – Clergyman

Moving to git in the time frame I'm operating under isn't an option. So, I need to solve my problem in SVN – Confection

Team Chose to move to git and merge problems seem to be gone. Now, we will use the team as a pilot to figure out if git's viable org wide. – Confection

Answer 2

We had similar issues due to similar circumstances and largely have solved them.

The major one is this:

If you are merging into your branch from trunk after the branch creation, you need to flag trunk with the branch commit (using svn merge --record-only), otherwise when you try to reintegrate back to trunk it tries to merge the commit of trunk to the branch back into trunk.

This obviously ends up reverting changes to trunk made after the later trunk->branch commit, tends to cause massive conflicts (especially tree conflicts if you created a new file or directory in trunk), etc.

So our process is to either never sync trunk into a branch after it's been created (works fine for short lived branches), or to do the following:

• branch b from trunk
• commits to trunk and branch
• reintegrate trunk into branch and commit (resolving conflicts but otherwise making no changes, even to compile)
• immediately do a svn merge --record-only of the trunk-to-branch commit revision
• fix any other issues with the branch and continue development
• reintegrate from the branch to trunk when done.

I found: http://www.collab.net/community/subversion/articles/merge-info.html helpful while working out what we were doing wrong.

Indeterminism

see also #3310102 – Indeterminism