Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

  (email not shown publicly)
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Thursday October 19, 2006
10:21 AM

merging both ways in subversion

[ #31359 ]

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:


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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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 []

  • 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 histor
    life is short
    • 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 []
      • 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...

        life is short
  • 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; []
    • 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
      • 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.