Please don't take the current prototypes for svn_fs_commit_txn and
svn_fs_merge as holy writ. Perhaps svn_fs_commit_txn should simply be
extended to hand back the same information that svn_fs_merge would, as
generated by the internal merge attempt.
To be honest, I have no idea even what svn_fs_merge should return; I'd
be happy to see its interface changed to return something clean and
sufficient and well-defined. I just couldn't see what that should be.
For example: the current interface for svn_fs_merge just returns the
name of a conflicting file; should it return a list of all conflict
points? Should there be some way to say what you want?
> Yoshiki Hayashi <yoshiki@xemacs.org> writes:
>
> > Karl Fogel <kfogel@galois.ch.collab.net> writes:
> >
> > > Yoshiki, have you read the section "Merge rules" in
> > > libsvn_fs/structure, or looked at the interface to svn_fs_merge() in
> > > svn_fs.h?
> >
> > Yeah, I've read it. My interpreteation is that svn_fs_merge
> > should be called by an editor when svn_fs_commit_txn returns
> > SVN_ERR_FS_CONFLICT error. If svn_fs_commit_txn
> > automatically calls svn_fs_merge, there's no way to return
> > conflict_p to the caller of svn_fs_commit_txn.
> >
> > do
> > commit_retval = svn_fs_commit_txn
> > if commit_retval equals SVN_ERR_FS_CONFLICT
> > do
> > retval = svn_fs_merge (merge differences between
> > base and latest fs revision)
> > if retval equals SVN_ERR_FS_CONFLICT
> > do something to resolve conflict (possibly with user interaction?)
> > or abort the svn transaction
> > while retval equals SVN_ERR_FS_CONFLICT
> > while commit_retval equals SVN_ERR_FS_CONFLICT
> >
> > is how I see resolving conflict works.
Received on Sat Oct 21 14:36:25 2006