On Fri, Jul 18, 2008 at 10:38 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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
>
>
Wow, that's a lot of info! I'll take a look. Thanks.
>
> > 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.
>
Making subtree merges and whole branches merges mutually exclusive is a
pretty big assumption. Is that explicitly stated anywhere so users know
what they're getting into? As far as releasing incremental merge tracking
functionality it is definitely a step forward, but hopefully not the end
goal.
> > 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.
>
Okay, that makes sense.
Received on 2008-07-18 18:07:55 CEST