[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Possible bug in merge tracking

From: Paul Burba <pburba_at_collab.net>
Date: 2007-06-04 20:19:30 CEST

> -----Original Message-----
> From: Mark Phippard [mailto:markphip@gmail.com]
> Sent: Sunday, June 03, 2007 11:38 AM
> To: dev
> Subject: Possible bug in merge tracking
> A repository dump file can be obtained here:
> http://merge-tracking.open.collab.net/servlets/ProjectProcess?tab=4
> A document that explains the repository can be found here:
> http://merge-tracking.open.collab.net/servlets/ProjectProcess?
> documentContainer=c2__Sample%20repository
> In the above example at r14 /branches/b is merged into trunk.
> This adds the following to the mergeinfo property value:
> /branches/b:11-13
> I believe this to be incorrect. Shouldn't it have added this:
> /branches/a:4-11
> /branches/b:11-13

Hi Mark,

I spent some time looking at this problem this morning. I'm not quite
sure what is going wrong yet and have to finish up some other TODOs
before continuing, but this script I'm using to reproduce your problem
with the greek tree might be of use to anyone who looks at it:

rem set URL to point to a vanilla greek repos

rem checkout WC
svn co %URL% merge_tests-1

rem r2 make a branch
svn copy %URL%/A merge_tests-1\A_COPY
svn ci -m "" merge_tests-1

rem r3 make a text mod on the branch
echo new content >> merge_tests-1\A_COPY\mu
svn ci -m "" merge_tests-1

rem r4 make a second branch
svn copy %URL%/A merge_tests-1\A_COPY_2
svn ci -m "" merge_tests-1

rem r5 make a text mod on the second branch
echo new content >> merge_tests-1\A_COPY_2\B\lambda
svn ci -m "" merge_tests-1

svn up merge_tests-1

rem r6 merge from first branch to second branch
svn merge %URL%/A_COPY merge_tests-1\A_COPY_2
svn ci -m "" merge_tests-1

# cwd == parent of merge_tests-1
>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1
Properties on 'merge_tests-1\A_COPY_2':
  svn:mergeinfo : /A:1-3

# Merge all outstanding revisions from second
# branch back to our "trunk" 'A'
>svn merge %URL%/A_COPY_2 merge_tests-1/A
--- Merging revisions 5-6:
U merge_tests-1\A\B\lambda
U merge_tests-1\A\mu
 U merge_tests-1\A

# 'A' is missing mergeinfo from 'A_COPY':
>svn pl -vR merge_tests-1
Properties on 'merge_tests-1\A':
  svn:mergeinfo : /A_COPY_2:5-6
Properties on 'merge_tests-1\A_COPY':
  svn:mergeinfo : /A:1
Properties on 'merge_tests-1\A_COPY_2':
  svn:mergeinfo : /A:1-3

A parting thought, while debugging 'svn merge %URL%/A_COPY_2
merge_tests-1/A' the svn_wc_diff_callbacks2_t dir_props_changed, i.e.
merge.c:merge_props_changed(), calls svn_wc_merge_props() on "A" and
passes original_props which contain '/A:1-3'. This seems odd, since 'A'
has no mergeinfo prior to the merge(?).


> branch a had previously been merged into branch b. So when
> branch b was merged into trunk it got the changes from both a
> and b. It seems like the change to the mergeinfo property of
> branch b should have been merged into the property on trunk,
> and that would bring along this change.
> The result of this property not being updated like this on
> trunk is that if you run this command from a trunk WC:
> svn merge $R/branches/a
> You get this:
> --- Merging revision 6:
> --- Merging revisions 8-17:
> A products/roadmap.html
> When you really should just get nothing since it has already
> been merged. In the above case, that file is not really
> added. svn st after running this command just reports:
> M .

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 4 20:20:20 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.