Jim Blandy <jimb@savonarola.red-bean.com> writes:
> 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?
Yah; will feel free to tweak as necessary, thanks.
-K
> > 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