> On Wed, 01 Nov 2006 20:56:10 +0530, Garrett Rooney wrote:
...
> >On 10/31/06, Daniel Rall <dlr@collab.net> wrote:
> >For smoother merging on the merge-tracking branch, I'll be adding a
> >conflict resolution callback to the client API. This callback will be
> >used by svn_client_merge3() when a merge into an already-conflicted
> >file is encountered (eventually, I'll try to use it to whenever a
> >conflict occurs so that it can be resolved on-the-spot). Right now,
> >the API looks like this:
> >
> > typedef svn_error_t *(*svn_client_conflict_resolver_func_t)
> > (const char *path,
> > void *baton,
> > apr_pool_t *pool);
> >
> >Alternately, this API could return some sort of status indicating the
> >state of PATH after its resolution attempt, which could help keep the
> >code to actually perform the 'resolve' operation for a conflicted path
> >inside Subversion's core (instead of duplicated across client
> >implementations).
>
>Are you planning on putting the user into an interactive merge type
>situation?
The Plan is that this API should allow for interactivity in such a
situation. For starters, the default behavior -- used when no such
callback is provided via the svn_client_ctx_t -- will be to error out.
Eventually, I'd like to have the command-line client be able to
specify something like "original", "new", or "mine", a la svk and
ClearCase. Both a prompt interface, and a command-line interface for
use in conjunction with --non-interactive are up for consideration
here.
> I wonder how that might interact with RA layers that are still
> pulling down merge operations from the network...
The way 'merge' is implemented today on the merge-tracking branch, we
pull the diffs down one revision range at a time, after accounting for
"already merged" revisions from the requested range.
The logic which detects merge conflicts and invokes the conflict
resolution callback lives in the tree delta editor used with the calls
to svn_ra_do_diff2() and svn_ra_reporter2_t->set_path() which drive
the actual merge.
One possible problem which might be able to occur here would be if
this sequence of API calls doesn't pull the entire tree delta down
before starting the editor drive (does it?? is it RA implementation
dependent??), and we timeout on the network waiting on the user to
finish resolving the conflict (e.g. we don't complete the download of
the remainder of the tree delta in time).
Thoughts?
- Dan
- application/pgp-signature attachment: stored
Received on Sat Nov 11 03:31:08 2006