All the Perl that's Practical to Extract and Report

merging both ways in subversion

rjbs on 2006-10-19T15:21:46

We have had no end of trouble managing branches, lately, and for no clear reason. This is how we generally introduce a big change:

  1. svn cp trunk branches/branch 2. work in the branch and in the trunk 3. occasionaly svn merge trunk-to-branch, merging from last merge to head 4. when done with branch, merge trunk into it one last time 5. try to merge branch into trunk 6. curse loudly

Step 5 always gives me grief. I try to use the suggested command:

svn merge --dry-run URL-TO-TRUNK@HEAD URL-TO-BRANCH@HEAD

This does crazy things, like show that it's going to a huge mess of files. If I drop the --dry-run, I get weird errors about what URL things claim to be using. I asked #svn, where I got one response suggesting that my URLs were wrong. They were not -- I checked them a dozen times.

Finally, I resorted to rsyncing, which made me feel ashamed. Has anyone else had this sort of difficulty?

More and more, I think I'll be moving my personal svn to darcs.

darcs and svn

markjugg on 2006-10-20T01:51:48

I use darcs by preference and svn or svk by requirement. Sometimes projects I'm contributing to require it.

From using both kinds of systems, I know I'm simply more productive with darcs, including less merging difficulties, as you described above.

To explain in more detail how darcs helps me be more productive, I created this page which compares darcs workflow with Subversion's

You can't do that

melo on 2006-10-20T10:08:10

Sorry :).

The problem is that you are trying to apply changeset X twice to trunk.

Let me try to explain. Please note that I'm not a wizard or expert of source control systems, but I think I know this one. :)

You start the branch at revision 10, then you commit 11, 12, 13 to branch.

You then do 14 to trunk and merge to branch. branch now has modifications made in trunk that you commit as rev 15.

Now if you try to merge with trunk, there are two changesets that do the same thing: 15 and 14. Subversion as no history of patches applied to each branch to know that we must apply 11, 12 and 13, and leave 15 alone because he already has it as r14.

darcs knows this, I think mercurial also knows and probably tla-family (bazaar and others). svk seems to know but I haven't tested.

Personally, I use darcs, not just because of this, but also due to selective commits.

Hope it helps,

Re:You can't do that

rjbs on 2006-10-20T10:50:23

The SVN book seems not only to state that what I suggested is possible, but to endorse it. The relevant section, including use snippet, is under Feature Branches here: svn book

Re:You can't do that

melo on 2006-10-20T11:07:56

Ahhs.. I see...

Ok, different expectations. Working with darcs, I expect that after the last merge from branch to trunk, the systems knows which revisions from branch where merged.

This is very helpful, because the next merge from branch to trunk should only merge the subsequent revisions on branch.

In Subversion, they just diff the two, and apply the diff to the trunk. It loses track of which changeset's where merged.

Yes, I see how this works now. So we are down to svn command line syntax to make it work...

I think I'm spoiled with darcs. I just don't think about this things anymore...

Sorry for the line noise.

Use "svnmerge"

nik on 2006-10-20T16:53:08

Sounds like you need svnmerge, which ships in the Subversion contrib/ directory.

I wrote a walkthrough showing how to use it that might be useful; http://wikitest.freebsd.org/SVN_Merging

Re:Use "svnmerge"

runrig on 2006-10-25T17:44:12

This sounds cool (and thanks for writing up the example), but I was wondering about another scenario. What happens when you complete your project branch (with occasional merging of trunk to branch), you've merged it to the trunk, and then someone decides that you need to merge this project into an older version branch (say to deliver to a customer on an older version)? Is it easy to cherry pick the revisions that relate to the project, skipping the revisions where you were merging the trunk into the project? Must you decide in advance which directories are mergeable to each other?

Re:Use "svnmerge"

rjbs on 2006-10-28T04:19:39

You'd have to do it by hand, looking for the ranges of revisions between merges from trunk.

I think it would be tedious and annoying. I think the svnmerge program would help make it less so.