On Wed, Jul 16, 2008 at 1:08 PM, J J <eggsgloriouseggs_at_gmail.com> wrote:
> 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).
Correct. This is something we are frequently discussing though, and
it could change.
> 2) After performing a merge, you can perform another merge before checking
> in the first merge results (except when using --reintegrate).
Yes. Which is of course good and bad.
> 3) If you run "svn merge url:/repo/trunk/foo.c", mergeinfo is stored in
> foo.c
Stored in the svn:mergeinfo property on foo.c. Yes.
> 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.
Yes. This is called elision. If all of the subtree mergeinfo is now
accounted for at a parent level, the mergeinfo should "elide" away to
the parent. NOTE: If we were to change your question #1 it would
remove, or at least limit, the ability to do this.
> 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'
Yes. But this is also needed for all of the previous as well. If
your repository is not at 1.5, merge tracking information is not
created.
> 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?
Well, it gives the "correct" results, it might not give the expected
results. Consider a revision that changes folder1/foo.c and
folder2/bar.c. In your branch you merged the changes to folder1 and
not folder2. If you later do a 2-URL merge, it will look like you
removed the changes in folder2 and so those changes will now be
removed from trunk. That probably would not be what you expected.
> 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)?
Remember that reintegrate is a short cut to a 2-URL merge, which is
essentially a fancy diff and apply operation. Reintegrate figures out
one of URL_at_REV pairs for you. It basically looks for the last REV
that was merged to the branch. In your example, this REV does not
change, so each merge does the exact same thing each time. What you
would need is something in between these steps to advance the REV on
the branch.
> 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?
They are "best practices" and I think it was a matter of some people
wishing that normal merges did do those checks. In the CollabNet
Merge client, we allow you to run those checks as part of any merge.
In the case of reintegrate, it is also because the merge is
essentially a diff + apply and the command is founded upon the idea
that you only branch and merge at the entire branch level. If you
start changing that promise you now remove yourself as a candidate for
using this option. So it is just trying to enforce that and keep
things clean.
> 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. :-)
Picture you have two folders, folder1 and folder2. folder1 has
explicit mergeinfo and folder2 does not. If you move something from
folder2 to folder1, it needs to create explicit mergeinfo on the item
you moved, so that Subversion knows that the file has a different set
of revisions then its parent folder. If the parent with mergeinfo is
the same before and after the move, which would be typical in the
normal cases, there really is no good reason to create explicit
mergeinfo. This is the sort of optimization that needs to be made.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-16 20:01:46 CEST