Re: Merge conflicts

This is a multipart message in MIME format.
--=_alternative 00457ECB85257279_=
Content-Type: text/plain; charset="US-ASCII"

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.


--=_alternative 00457ECB85257279_=
Content-Type: text/html; charset="US-ASCII"


<br><tt><font size=2>You should still set the auto-merge-set property in
this case,</font></tt>
<br><tt><font size=2>rather than the merge-set, since the main purpose
of distinguishing</font></tt>
<br><tt><font size=2>between these two cases is to let the client know
whether to just</font></tt>
<br><tt><font size=2>present the checked-out content for review (the auto-merge
case),</font></tt>
<br><tt><font size=2>or to run a client-side merge tool before showing
the content for</font></tt>
<br><tt><font size=2>review (the merge case).</font></tt>
<br>
<br><tt><font size=2>Note that there is not much special a generic client
can do in the</font></tt>
<br><tt><font size=2>&quot;auto-merge-with-conflict&quot; case, beyond
saying &quot;there is something</font></tt>
<br><tt><font size=2>in here you have to fix, but I don't know where&quot;.
&nbsp;In this case,</font></tt>
<br><tt><font size=2>you'd probably have the server throw an error at checkin
time if</font></tt>
<br><tt><font size=2>the conflicts have not been resolved (since it knows
the format that</font></tt>
<br><tt><font size=2>it uses to represent conflict in content).</font></tt>
<br>
<br><tt><font size=2>Of course, if you have a special-purpose client that
knows the format</font></tt>
<br><tt><font size=2>that a particular server uses to represent auto-merge
conflicts, </font></tt>
<br><tt><font size=2>it can scan for those conflicts when it gets an auto-merged
result,</font></tt>
<br><tt><font size=2>and give suitable guidance to the user. &nbsp; </font></tt>
<br>
<br><tt><font size=2>Cheers,</font></tt>
<br><tt><font size=2>Geoff</font></tt>
<br>
<br><tt><font size=2>Werner wrote on 02/05/2007 06:01:51 AM:<br>
&gt; If a merge request allows for automatic merging of documents<br>
&gt; and if the server has this possibility for a certain type<br>
&gt; of documents, it can happen that the automatic merge module<br>
&gt; detects conflicts.<br>
&gt; <br>
&gt; Is it allowed to update the &quot;merge-set&quot; property in this
case<br>
&gt; instead of the &quot;auto-merge-set&quot; property?<br>
&gt; <br>
&gt; And is it then allowed to update the body of the checked-out<br>
&gt; resource in such a way that a client can present the result<br>
&gt; to the user and let him make the choices to resolve the<br>
&gt; conflicts? The automatic merge module would of course have to<br>
&gt; document what it generates in such a case.<br>
&gt; <br>
&gt; The use case for this is when the merge software is not<br>
&gt; available to the client, but only to the server.<br>
<br>
</font></tt>
--=_alternative 00457ECB85257279_=--