On Fri, Jul 18, 2008 at 10:47 AM, J J <eggsgloriouseggs_at_gmail.com> wrote:
> 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?
Have you read Paul Burba's mergeinfo "manifesto"? It might offer some
clues. It is linked from this blog:
http://blogs.open.collab.net/svn/2008/05/subversion-15-1.html
> 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.
A local svn move adds empty mergeinfo. It does not so that it can
avoid contacting the repository during the merge, but leave behind a
marker for the commit process to decide what to do. I'd think that
commit would see the server does not support mergeinfo and remove the
property or something. Not really sure though.
> 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?
Yes. Basically, 2-URL merge is just going to diff what you tell it.
It is not hard to imagine scenarios where that is not the result you
really want. The reintegrate option tries to recognize these
situations and stop you.
> 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)?
Not really. There isn't any mechanism to update the branch, so I do
not see a lot of opportunity to resolve it.
> 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.
It is fine to merge on sub-directories or files. What is not fine, is
to try to mix that with whole branch merges. The theory behind
reintegrate was that users were likely to do one or the other. The
big wrench stuck in the spokes of that idea was move/rename creating
this information.
> 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?
It does not look like it will make it into 1.5.1, which is being cut
next week. The idea behind the fix would be that if the parent
containing mergeinfo is the same before and after the merge, then
there is no need to create mergeinfo.
--
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-18 17:38:31 CEST