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

Re: Best way to reintegrate on 1.4 server

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: Thu, 10 Jul 2008 22:23:11 +0100

2008/7/10 Jeff <jsbmsu_at_gmail.com>:
> I am very new to SVN, but have been reading the Subversion book and
> the TortoiseSVN manual. Unfortunately, for now I am stuck working on
> a server with Subversion 1.4 installed, and am trying to determine the
> best way to manage merging a branch back into the trunk.
> 1) The Subversion 1.4 book says to check out the trunk, and compare
> the head revision of the branch with either a) the revision at which
> the branch was created or b) the last revision at which the trunk and
> branch were in sync. These changes are merged to the working copy of
> the trunk, which you can then commit. For example, for the first time
> merging branch changes back to trunk:
> # if branch was created in r341, and we just updated trunk WC to
> arrive at r405
> $ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
> $ svn commit -m "Merged my-calc-branch changes r341:405 into the
> trunk."
> These are the only supplied instructions for this task, so presumably
> it is meant to work whether none, some, or all of the meantime trunk
> changes have been merged into the branch already.

Actually there is a very long and detailed section in the subversion
book, but I agree it's not a trivial topic.

The instructions you see here are for merging a range of revisions
from one branch to another, and they assume that all those changes are
branch changes as opposed to trunk changes which have been merged back
into the branch.

> 2) The TortoiseSVN 1.5 manual says in section 5.19 that the "Merge two
> different trees" option is the only way to merge branch changes back
> to trunk on a pre-1.5 system. The corresponding section, 5.19.3, says
> essentially to checkout the trunk, and then merge the trunk URL with
> the branch URL, specifying for both the revision at which they were
> last in sync.

This is a different technique, described in the svn book under the
heading 'Feature Branches'. Essentially you merge every (appropriate)
trunk change back into the branch so the branch always includes the
latest trunk changes as well as its own development changes. You check
this one more time just before you merge back and having done that,
trunk and branch are 'in sync'. Now the only difference between trunk
and branch is the branch change itself. What you would like to happen
now is for trunk to look exactly like the branch, and that's what the
URL merge does. It compare the branch and trunk at the last sync point
and merges the difference back into trunk so that it now looks like
the branch.

> Now, that certainly wouldn't make sense if they mean the last time
> they were exactly in sync, i.e. the last time a merge had occurred, as
> in (b) above. Rather, it seems this must mean the last time the
> branch had had all trunk changes merged into it. Thus, the current
> merge would find only the branch changes leftover, and, merge them
> with the trunk WC (with the WC presumably at the same revision as
> specified for this merge...clear as mud?)
> So, this differs from (1) because (1) has you compare two revisions of
> the branch, and (2) has you compare a trunk-changes-merged-in revision
> of the branch with the corresponding/same revision of the trunk.
> 3) Could you not also apply the method in (1) using the TortoiseSVN
> interface detailed in TortoiseSVN manual section 5.19.1? Checkout the
> trunk, specify the appropriate previous and current revisions of the
> branch, ex. 341-405 from above, which would calculate the branch
> changes and merge them into the trunk WC. You could then commit to
> trunk, as in (1).
> What is the reason for the discrepancy? Why does the Tortoise
> documentation (seem) to prefer (2) over (1)/(3)? Are there any flaws
> in my reasoning and understanding of the situation? (Is there some
> old post I should be reading that would have made this crystal clear?)

I may have oversimplified the 1.5 manual on the wrong assumption that
the server would likely be 1.5 as well. You may want to look at the
TSVN 1.4 manual which gives a better explanation of 'the Old Way'.

Essentially you have 2 choices.
1. Select all the changes that are part of the branch development,
ignoring any sync merges from trunk back to branch, and merge those
to trunk. For a small number of changes and no backports this is easy.
For a long-lived branch it is not.


2. Sync the branch to trunk (it's a good idea to keep the branch in
sync with trunk to avoid too great a divergence), backporting all
trunk changes to the branch, then do a URL merge to make trunk the
same as the synced branch.


: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-10 23:23:23 CEST

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

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