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

RE: [merge-tracking]: Problem with RA call to retrieve committed mergeinfo

From: Paul Burba <pburba_at_collab.net>
Date: 2007-03-28 19:00:17 CEST

 

> -----Original Message-----
> From: Paul Burba [mailto:pburba@collab.net]
> Sent: Thursday, March 08, 2007 10:47 AM
> To: dev@subversion.tigris.org
> Cc: Daniel Rall
> Subject: [merge-tracking]: Problem with RA call to retrieve
> committed mergeinfo
>
> Dan,
>
> Yesterday in IRC:
>
> [18:53] dlr: Do we even care about this case -- does it
> (issue #2733) only come up when there's local merge info?
> [18:54] dlr: For committed merge info, our RA call to
> retrieve inherited merge info should catch it, no?
> [18:54] pburba: Yes, it does, just doesn't properly handle it
> though, but I think I almost have that fixed.
> [18:54] pburba: By handle, I mean it doesnt get set on the
> merge target, but it's there.
> [18:55] dlr: Once you've fixed that, don't we only care about *local*
> (uncommitted) merge info?
> [18:55] dlr: ...since we already retrieved the committed
> merge info from the repository?
> [18:55] pburba: Yes
> [18:56] dlr: So I can ignore this nasty, nasty edge case.
> [18:56] dlr: yay!
> [18:56] dlr: well, sort of
> [18:56] pburba: Yay! I think...why do I feel like Im missing
> something though.
>
> I realized what it was I was missing. The RA call to
> retrieve the repos merge info (svn_ra_get_merge_info) might
> not get the info for HEAD which means we miss mergeinfo if
> our WC is not up to date, for example:
>
> Starting with the normal greek tree:
>
> r2 Copy /A to /A_COPY
> r3 Mod /A/D/H/psi
> r4 Mod /A/D/G/rho
> R5 Mod /A/B/E/beta
> r6 Mod /A/D/H/omega
> r7 Merge r4 /A/D --> /A_COPY/D
>
> Mergeinfo is what we expect:

Uh, no it's not :-P

> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:4
                           ^^^
                   should of inherited
                       r1 from A_COPY
 
> Now we merge r6 /A/D/H --> /A_COPY/D/H
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,4
> Properties on 'merge_tests-1\A_COPY\D\H':
> svn:mergeinfo : /A/D/H:1,6
                           ^^^
                   should of inherited
                       r4 from A_COPY\D

> Mergeinfo for our target doesn't pick up r4. The problem is
> svn_client__get_merge_info_for_path() passes the working copy
> revision which eventually gets passed to
> svn_ra_get_merge_info() and it does as we ask it and returns
> the mergeinfo from the repos for r2, which obviously doesn't
> include r4.
>
> >svn st -v merge_tests-1\A_COPY\D\H
> M 2 2 jrandom merge_tests-1\A_COPY\D\H
> 2 2 jrandom merge_tests-1\A_COPY\D\H\chi
> M 2 2 jrandom
> merge_tests-1\A_COPY\D\H\omega
> 2 2 jrandom merge_tests-1\A_COPY\D\H\psi
>
> If we revert, update the WC, and repeat the merge it works fine:
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,4
> Properties on 'merge_tests-1\A_COPY\D\H':
> svn:mergeinfo : /A/D/H:1,4,6
>
> I'm thinking we should ask the repos for '\A_COPY\D\H's
> mergeinfo at the high end of whatever range we are trying to
> merge into the the target,
> r6 in this case. Or maybe the highest rev of it's nearest
> ancestor's mergeinfo? Thoughts? I'm starting to see the
> edge case hell you describe...

Just wanted to put this thread to rest. As noted above the problem was
actually related to mergeinfo inheritance not working at the time.

Paul B.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 28 19:00:51 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.