On Jan 27, 2008 10:24 AM, Mark Phippard <markphip_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-28 17:39:16 CET