On Wed, Apr 25, 2012 at 08:37, Philip Martin <philip.martin_at_wandisco.com> wrote:
> gstein_at_apache.org writes:
>
>> + else
>> + {
>> + SVN_ERR_ASSERT(err != NULL);
>> + if (err->apr_err == SVN_ERR_FS_CONFLICT)
>> + {
>> + /* Case 2. */
>> +
>> + /* Copy this into the correct pool (see note above). */
>> + *conflict_path = apr_pstrdup(result_pool, inner_conflict_path);
>> +
>> + /* Return sucess. The caller should inspect CONFLICT_PATH to
>> + determine this particular case. */
>> + svn_error_clear(err);
>> + err = SVN_NO_ERROR;
>> + }
>
> By clearing err we limit the information about the conflict to just the
> conflict path--if there is a more detailed explanation in err it is
> discarded. Is that what we want? The FS layers detect all sorts of
> conflicts that could be described in err, although they don't do so at
> present.
Well... only described in a human-readable fashion. The only
programmatic piece we have is conflict_path. The code can't do much
based on the human-readable portion except maybe get that sent back to
the user.
And as you note: the string is set by
libsvn_fs_*/tree.c:conflict_err() and is very simplistic. I deemed it
"okay" to toss that out, in favor of trying to simplify the various
result conditions of committing.
Do you think that is going to change any time soon?
Part of the problem here is returning an error (from the underlying
svn_fs_commit_txn()) *and* expecting the caller to examine an OUT
parameter. We normally state OUT parameters are invalid upon an error
return. I didn't want to propagate that behavior to this function's
error/OUT behavior.
> I suppose that the user resolves the conflict by updating the working
> copy, but that assumes that there is a working copy and that the update
> will use the same revision and get the same conflict.
An 'svn update' might not produce a conflict, but simply merge some
unrelated text into the file. The server can't do that, but the client
is much smarter there.
Cheers,
-g
Received on 2012-04-25 22:25:59 CEST