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

Re: Problems selecting trunk revisions to merge to branch.

From: Paul Burba <ptburba_at_gmail.com>
Date: Thu, 5 Mar 2009 11:49:26 -0500

On Tue, Mar 3, 2009 at 12:01 PM, Jurko Gospodnetić
<jurko.gospodnetic_at_docte.hr> wrote:
> Hi all.
>
>   I have two repositories affected by the following problem.
>
> Repositories have with a trunk and a branch split off of the trunk (they
> actually have more tags and branches than that in them but these are the
> relevant parts to this problem description). In both cases there are no
> branches split off the aforementioned branch and no merges have ever
> been done from the trunk onto the branch.
>
>   Now, when I attempt to merge all trunk revisions into the branch,
> Subversion seems to include all the revisions prior to BRANCH-POINT as
> well as those after BRANCH-POINT in the merge, obviously causing lots of
> conflicts in the process.
>
>   In one case I can reproduce the problem by doing the following:
>     * Check out the source folder from the trunk as Trunk.
>     * Check out the source folder from the branch as Branch.
>     * Move into the Branch folder.
>     * Run the following command:
>
>> C:\_\Branch>svn merge --dry-run ..\Trunk
>> --- Merging r3404 through r7675 into '.':
>> [snipped lots of lines including lots of conflicts]
>
> The source folder in question has been created in revision 3403, the
> branch has been split off in revision 7613, commits on the branch have
> been 7613 & 7619, and the trunk revisions affecting the source folder
> after the branch are 7622, 7625, ... all the way up to the 7658. The
> trunk itself has more commits not affecting the source folder in
> question and HEAD == 7675.

Hi Jurko,

At first glance this does appear to be a bug. However our test suite
tests many scenarios like this without any problems and I and many
others do this type of merge frequently without problem. So I suspect
you are running into some sort of edge case. Did you actually try the
real merge too (i.e. not a --dry-run). Did you get the same results?
Is your repository publicly accessible?

> Viewing the revision graph in the latest (1.5.9) TortoiseSVN displays
> the branch correctly and log for the branching revision correctly lists
> that the branch folder has indeed been added as a copy of its original
> source folder on the trunk.
>
> Doing the same merge operation through TortoiseSVN has the same
> effect as when using the command-line client.
>
> Attempting to do --record-only merge on revisions 0:BRANCH-POINT does
> nothing, i.e. makes no modifications to the working folder such as
> updating the mergeinfo property and there are no changes to commit after
> such a merge:

Good thought, but merge tries *not* to record explicit mergeinfo on a
path which overlaps with that path's 'natural history'. This was
mainly done to reduce the amount of explict mergeinfo and to a lesser
extent to avoid confusion.

Paul

> Explicitly specifying that I want to merge only revisions after
> BRANCH-POINT works as expected.
>
> Equivalent problem occurs in a separate repository where the whole
> trunk folder has branched and not just one of its subfolders. There we get:
>
>> C:\_\Branch2>svn merge --dry-run ..\Trunk2
>> --- Merging r2 through r13100 into '.':
>
>   even though the branch has been created in revision 13045. (Here the
> HEAD revision is 13100.)
>
>   Is this a bug? Possibly a known one? Or am I doing or interpreting
> something wrong here? Could there be something messed up with my
> repositories? Any suggestions on how to test this further?
>
>   Many thanks.
>
>   Best regards,
>     Jurko Gospodnetić
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1262109
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1272825
Received on 2009-03-05 17:49:56 CET

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

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