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

Best way to reintegrate on 1.4 server

From: Jeff <jsbmsu_at_gmail.com>
Date: Thu, 10 Jul 2008 07:42:36 -0700 (PDT)

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

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.

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.

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?)

Thanks -- Sorry for the length; trying to be clear

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 17:05:01 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.