On Wed, Jul 16, 2008 at 1:01 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
I have noticed that doing a complete merge repeatedly from trunk to the
branch doesn't elide away subtree mergeinfo unless you do an update first on
the branch working copy first. A test case (test2.sh) is attached. Can you
explain why?
> > 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.
>
I see. I got confused because the 1.5 client still adds empty mergeinfo in
some cases, even though the repository isn't upgraded. Subsequent merge
attempts remove that mergeinfo though, which I didn't notice before.
Everything is working as expected after the upgrade.
>
> > 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.
Okay. So the issue is that the 2-URL merge can't account for the fact that
parts of revisions have already been merged to the branch that will be
reintegrated back to trunk, and thus the diff is not what the user would
expect. Right?
> > 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.
I see that if after performing a reintegrate from branch to trunk I then do
an empty merge from trunk back to branch, then reintegrating from branch to
trunk works because it uses the new revision. (See attached test1.sh to
reproduce this) This doesn't seem very intutive to me, but at least I'm
getting a better handle on how merge tracking actually works. Has anyone
been bouncing around ideas for improving this (i.e. for updating the
revision to use after merging everything from the branch back to trunk)?
> > 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.
>
This makes sense as long as users understand they really shouldn't be
merging on sub directories or files, even though the tool lets them.
Assuming they understand this, the only confusing part then would be the
creation of subtree mergeinfo on copy/move/rename, thus preventing
reintegrate from happening. I don't entirely understand what will be
included in 1.5.1, but hopefully there will be a fix for this.
>
> > 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.
Ah, I see! The light has been turned on! Can you provide any info on
how/if this will be smarter in 1.5.1?
Thanks so much for your explanations.
Justin
---------------------------------------------------------------------
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-18 16:48:02 CEST