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

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

From: Paul Burba <pburba_at_collab.net>
Date: 2007-03-08 16:47:04 CET

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:

>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

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

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...

Paul B.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 8 16:47:17 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.