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

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.