[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: question on svn merge without revision numbers

From: Brummer, Byron <ByronBrummer_at_LiveNation.com>
Date: 2007-07-24 22:42:08 CEST

> Almost all the documentation I've seen on svn merge suggests
> using a revision number for things to merge. Is this really necessary?


> Let's say I create a branch called foo and work on it for a while. Then I
> want to merge it back into the trunk. Can I just do
> svn merge <URL-for-branch> <URL-for-trunk> <URL-for-trunk>
> to merge it back into the trunk?

        Unless trunk has not changed since branch was cut, no. The problem is
        that your diff will be what is different between branch and trunk
        (which likely has changed), while what you want to merge is the
        difference between the start of the branch (when it was cut) and the
        end of the branch (head).

        That said, I hear the merge tracking features can manage this for you
        a little more sanely.

> Similarly, if I want to merge the
> trunk into the branch, can I just do
> svn merge <URL-for-trunk> <URL-for-branch> <URL-for-branch>

        Going back and forth generally will cause a mess without some tight
        tracking added to the mix. What you created on branch will get merged
        to trunk, then attempted to merge *back* to the branch and conflict.
> What are the issues that make the svn documentation focus so heavily
> on doing merges by revision number? If your branch has 20 revisions,
> doesn't it get painful to have to do a separate merge command for each
> revision?

        Script it out.

        Personally I merge one rev at a time, separately committed using the
        original's log message (and info) so that I know where the merged
        changes actually came from. The new merge tracking features may help
        this; I haven't had a chance to play with them yet.

        I tried using SVN's broken idea of a "tag/label" to track merge
        points, but along with losing information (the history) it also would
        just do "odd" things. It was common for it to create a conflict where
        there logically can't be one (the target hasn't changed). I finally
        gave up on the idea of merging more then one revision at a time, ever;
        SVN just doesn't handle it reliably and conflict or not I couldn't
        trust it.

        One rev at a time, scripted, coping the original rev's log message
        including the rev #. Works great, very reliable, and history is
        maintained (that last part is *hugely* important to me).


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 24 22:41:15 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.