Re: Merge conflicts

You should still set the auto-merge-set property in this case,
rather than the merge-set, since the main purpose of distinguishing
between these two cases is to let the client know whether to just
present the checked-out content for review (the auto-merge case),
or to run a client-side merge tool before showing the content for
review (the merge case).

Note that there is not much special a generic client can do in the
"auto-merge-with-conflict" case, beyond saying "there is something
in here you have to fix, but I don't know where".  In this case,
you'd probably have the server throw an error at checkin time if
the conflicts have not been resolved (since it knows the format that
it uses to represent conflict in content).

Of course, if you have a special-purpose client that knows the format
that a particular server uses to represent auto-merge conflicts, 
it can scan for those conflicts when it gets an auto-merged result,
and give suitable guidance to the user. 

Cheers,
Geoff

Werner wrote on 02/05/2007 06:01:51 AM:
> If a merge request allows for automatic merging of documents
> and if the server has this possibility for a certain type
> of documents, it can happen that the automatic merge module
> detects conflicts.
> 
> Is it allowed to update the "merge-set" property in this case
> instead of the "auto-merge-set" property?
> 
> And is it then allowed to update the body of the checked-out
> resource in such a way that a client can present the result
> to the user and let him make the choices to resolve the
> conflicts? The automatic merge module would of course have to
> document what it generates in such a case.
> 
> The use case for this is when the merge software is not
> available to the client, but only to the server.