[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] svn_fs_commit_txn

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-03-08 14:39:39 CET

Yoshiki Hayashi <yoshiki@xemacs.org> 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.

Yes, there is -- svn_fs_commit_txn can just return the appropriate
error, as its doc string says.

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

This is an archived mail posted to the Subversion Dev mailing list.