At a high level, agreed that explicitly exposing more details of
reintegrate's semantics would be a good thing.
However, I'm not convinced that having three separate APIs as you
suggest is a good idea. Are they generally reusable, or do they only
make sense when called in sequence, one after the other?
(In the latter case they should get namespaced appropriately, or made
into callback functions that the public reintegrate API calls.)
Julian Foad wrote on Thu, Dec 08, 2011 at 12:17:32 +0000:
> The current 'reintegrate' merge consists conceptually of two stages:
>
> * Determine what the equivalent two-URL merge is.
>
> * Do the two-URL merge.
>
> as well as checking that the target WC is clean and the source and
> target are ancestrally related.
>
>
> My gut feeling tells me that the libsvn_client API would be better if
> it presented these as two separate functions. A small but distinctly
...
> The reintegrate merge up till now goes like this:
>
> client code (such as subversion/svn/merge-cmd.c)...
> |
> |- svn_client_merge_reintegrate()
> | |
> | |- check target WC is a clean single-revision WC
> | |- check source and target are related
> | |- determine URLs and revs of src, tgt, and common ancestor
> | |- do a 2-URL merge
>
> and with this patch it goes like this:
>
>
> client code (such as subversion/svn/merge-cmd.c)...
> |
> |- svn_client_ensure_wc_is_suitable_merge_target()
> | |
> | |- check target WC is a clean single-revision WC
> |
> |- svn_client_find_reintegrate_merge()
> | |
> | |- check source and target are related
> | |- determine URLs and revs of src, tgt, and common ancestor
> |
> |- Tell the user what equivalent two-URL merge we're doing
> |
>
> |- svn_client_do_reintegrate_merge()
>
> | |- do a 2-URL merge
...
> Any comments on this approach?
>
> - Julian
Received on 2011-12-08 13:38:26 CET