Karl Fogel <kfogel@galois.collab.net> writes:
> Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> > 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.
>
> Yes, there is -- svn_fs_commit_txn can just return the appropriate
> error, as its doc string says.
Sorry, Yoshiki. I misread your first paragraph, and gave an
irrelevant (and needlessly obnoxious, sorry) response above. You
weren't asking about the error, but about the conflict_p thing.
Probably svn_fs_commit_txn should return conflict_p too, just passing
up whatever it got from svn_fs_merge. We should make failures provide
as much useful information as possible.
-Karl
> There are two kinds of "conflicts" here. Some conflicts cannot be
> resolved by the repository. For example, if two users made changes to
> the same file, then someone is going to have to resolve that
> conflict. The repository cannot do it.
>
> But other conflicts can be resolved by the repository -- for example,
> when two users add different new files to the same directory. Say
> that first Jane adds foo.c, and then Bill adds bar.c, to directory D,
> and both started with the *same* base revision of D. It's true that
> when bar.c gets committed, D has already changed since base (because D
> has received foo.c), but this can and should be automatically resolved
> by the filesystem, through the appropriate merge. This is the sort of
> situation svn_fs_merge handles gracefully.
>
> Here's a question that might help you: If the caller of
> svn_fs_commit_txn were also responsible for calling svn_fs_merge, then
> why does svn_fs_commit_txn *return* the new revision number by
> reference? In the scenario you're describing, the caller would know
> that number already, and wouldn't need to be told it.
>
> This is why I'm saying that callers of svn_fs.h just call
> svn_fs_commit_txn and let it do all the hard work. I understand it's
> confusing that svn_fs_merge is also a public interface, but I think
> Jim just put it there because of an intuition that it might be useful
> to expose it. Nevertheless, svn_fs_commit_txn should call
> svn_fs_merge internally.
>
> -Karl
>
> > 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.
> >
> > --
> > Yoshiki Hayashi
Received on Sat Oct 21 14:36:25 2006