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

Re: [PATCH] Split up the reintegrate merge API: first find what to do, then do it - v2

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 12 Dec 2011 18:28:15 +0000 (GMT)

Paul Burba wrote:
> Julian Foad wrote:

>> If step 2 could repeat the same check as step 1, that would be useful
>> for your scenario, but otherwise there's little point in step 2 doing
>> a partial check.  So for now I'll take the simple solution which is to
>> call svn_client_merge4(allow_mixed_rev=TRUE) to bypass the check.
>>
>> If and when we want to perform the full check in step 2, then we'll
>> want to alter svn_client_merge4() in some way to provide more control
>> over those checks, or else expose the check function separately.  The
>> best way might become clearer with further work on the APIs.
>
> Agreed, this can be dealt with later (if it needs to be dealt with at all).
>
> Overall I think this patch looks good.  The only problem I see is:
[...]
> svn_client_find_reintegrate_merge() takes an absolute WC path, but we
> might be passing it a relative path here.  That will ultimately cause
> an assertion in wc_db.c:

Yup, I found that too.

I also avoided the work duplication in the reimplementation of svn_client_merge_reintegrate(): I made the internal find_reintegrate_merge() function return the sessions and youngest common ancestor revision, so that merge_reintegrate_locked() can call merge_cousins_...() directly instead of calling the higher-level merge_locked().

Committed in this form in r1213349.

Thanks for looking.

- Julian
Received on 2011-12-12 19:28:54 CET

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.