Observations on merge tracking from current HEAD

[Mark Phippard <ma...@gmail.com>]

I ran through the process of creating the merge tracking sample
repository using the latest trunk code.  For an overview of what this
repository looks like take a look at this document that explains each
of the steps in the process:

http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentContainer=c2__Sample%20repository

First, a general observation, is that everything worked smoothly.  The
merges that occur in revisions 6, 14 and 17 now use the --reintegrate
merge option.  The merges in revisions 12 and 15 use the "merge all
revisions I do not already have style of merge".

I did not run into any real problems during the process.  There were
two things worth pointing out as maybe they are areas we want to make
a change.

1) r12 - merges branch a to branch b

The mergeinfo handling for this merge seems sub-optimal.  It did not
appear to create any problems though.  /branches/a does not have any
svn:mergeinfo property.  This is because nothing is ever merged to
this branch during the process.  It does of course no that it was
created from trunk @ r2.  When this branch is merged to branches/b, it
creates mergeinfo on /branches/b that includes the value of:

 /trunk:2

Given that /branches/b was created by copying /trunk at r9 this does
not seem right.  I did some tests (try to synch the branch with trunk)
and it seems like internally SVN knows what revisions it has and does
not try to do anything weird.

Of course in r14 when this branch is merged back to trunk, this same
mergeinfo about trunk gets added to trunk.  I think Paul Burba has
already proposed changing this.

So, summary for this item is that it all seems to work.  Perhaps we
could figure out a way to not add mergeinfo for revisions that we know
already exist in the target?

2) r15 - synchronize branches/c with latest trunk

This worked fine, however it appears that we removed the ability to
run this merge by simply typing svn merge.  I recall this was the
change cmpilato made many weeks ago and we ultimately agreed it was
the right thing to do?  I think there was a proposal to make this
merge interactive.  Ask the user what they want to do.  So I am mainly
reminding people of this "issue" in case we want to improve it.
Typing svn merge $REPOS/trunk worked fine.

I have not tried doing svn log/blame -g as it appears that Hyrum is in
the process of updating those.  Once those commands are working
correctly, I think that things will be looking pretty good for
release.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Observations on merge tracking from current HEAD

[Paul Burba <pt...@gmail.com>]

On Jan 27, 2008 10:24 AM, Mark Phippard <ma...@gmail.com> wrote:
> I ran through the process of creating the merge tracking sample
> repository using the latest trunk code.  For an overview of what this
> repository looks like take a look at this document that explains each
> of the steps in the process:
>
> http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentContainer=c2__Sample%20repository
>
> First, a general observation, is that everything worked smoothly.  The
> merges that occur in revisions 6, 14 and 17 now use the --reintegrate
> merge option.  The merges in revisions 12 and 15 use the "merge all
> revisions I do not already have style of merge".
>
> I did not run into any real problems during the process.  There were
> two things worth pointing out as maybe they are areas we want to make
> a change.
>
> 1) r12 - merges branch a to branch b
>
> The mergeinfo handling for this merge seems sub-optimal.  It did not
> appear to create any problems though.  /branches/a does not have any
> svn:mergeinfo property.  This is because nothing is ever merged to
> this branch during the process.  It does of course know that it was
> created from trunk @ r2.  When this branch is merged to branches/b, it
> creates mergeinfo on /branches/b that includes the value of:
>
>  /trunk:2
>
>
> Given that /branches/b was created by copying /trunk at r9 this does
> not seem right.  I did some tests (try to synch the branch with trunk)
> and it seems like internally SVN knows what revisions it has and does
> not try to do anything weird.

Mark,

I agree that having '/trunk:2' on 'branches/b' doesn't make any sense.
 I mentioned a closely related case here:

http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=134268

Like you, I haven't seen that it causes any problems (yet), but it
certainly adds unnecessary noise to the mergefinfo.

> Of course in r14 when this branch is merged back to trunk, this same
> mergeinfo about trunk gets added to trunk.  I think Paul Burba has
> already proposed changing this.

Yes, I've got a patch kicking around that eliminates this
"self-referrential" mergeinfo, see:

http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=134491

*But* currently this doesn't work when --reintegrate is used.  I also
discovered that it doesn't work unless it you specify a revision range
with -r.  I'm looking at what's involved in changing that patch to
work with reintegrate and fixing the problem when using a default
range.

Paul

> So, summary for this item is that it all seems to work.  Perhaps we
> could figure out a way to not add mergeinfo for revisions that we know
> already exist in the target?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org