Re: Problem with merge tracking in 1.5.0

> I finally got that blog post published.
>
> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
>
> It explains some of the issues with merge and reintegrate. Your issue
> is covered near the end under the Branch Management section. In your
> reproduction, Subversion is behaving as expected. You would probably
> want to handle this situation by deleting branches after they are
> reintegrated and then create them again if necessary.

Mark,

Thanks for the excellent post. Would you mind confirming my current
understanding of how merge tracking works, and then answering some remaining
questions I have? I would have posted to the collabnet forum, but the list
seemed like a better place to have this information recorded.

My Understanding
----------------
1) A merge will update the mergeinfo even if no merge was done, to increment
the merged revision (i.e. even if the revisions weren't on source branch
they are recorded in the mergeinfo).

2) After performing a merge, you can perform another merge before checking
in the first merge results (except when using --reintegrate).

3) If you run "svn merge url:/repo/trunk/foo.c", mergeinfo is stored in
foo.c

4) Merges performed at the top of the branch remove superfluous mergeinfo
from sub-directories / files
  since the entire revision is recorded in the mergeinfo stored on the
branch.

5) Before you can use --reintegrate, the repository must be upgraded with
"svnadmin upgrade /paht/to/repo". Otherwise you will receive the following
error:

    svn: Retrieval of mergeinfo unsupported by 'url://repo'

My Questions
------------
1) In the blog post you mention that a 2-URL merge for branches with subtree
mergeinfo doesn't always give the correct results. I don't yet understand
why this is the case. Would you mind explaining why in more detail? Is
this true only when the subtree mergeinfo is on the source branch or also
when it is on the destination branch?

2) You mentioned that reintegrate can't be performed more than once from the
same branch. I'm trying to understand what exactly the issue is. Here is
what I did and the results I got.

On branch a add line to foo.c and commit.
Merge with --reintegrate from branch a to trunk and commit.
On trunk remove same added line from foo.c and commit.
Merge again with --reintegrate from a and to trunk.
The line was added back to foo.c, whereas I would have hoped reintegrate was
smart enough to know I already reintegrated that change from branch a. See
attached script to reproduce this.

Can you explain why this happened (assuming you answer to 1 doesn't explain
this)?

3) As you mentioned, there are additional checks performed when using
--reintegrate (mixed revisions, no local mods, ancestry, subtree
mergeinfo). Besides the subtree mergeinfo check, can you explain why these
checks are needed with reintegrate and not in the case of normal merges?

4) In your post you say "why copy/move create mergeinfo are beyond the scope
of this post". Would you mind clarifying here? I'm sure the light bulb
will turn on for me with a little more explanation. :-)

Thanks,
Justin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org