svn_fs_commit_txn

Unless I completely misunderstand berkeley DB transaction,
some comments in svn_fs_commit_txn are wrong.

There's a comment that says:

   * There are a couple of ways to handle the walk that changes
   * mutable->immutable...
   *
   * Method A:
   *
   * When the merge is done, but before attempting the commit, walk
   * the txn tree changing mutable nodes to immutable, and recording
   * these actions in the trail's undo list. If the commit fails,
   * the undo list will be run.
   *

This is not necessary. You just have to commit it in one
trail. If the trail aborts, it aborts all changes made to
database in that trail. Mutable flag is stored in nodes
table so reverting is done automatically.

Other comment says:

  /* Try to commit the next revision. If someone already committed
     it, re-merge and try again. Else break outta here. */

This isn't necessary, either. You need to check last fs
revision before making nodes immutable. When you do it, you
acquire the lock of DB_ENV. No other thread can commit new
revision before the trail ends.

What I am saying is, all you need to do is to replace return
SV_ERR_FS_CONFLICT with a call to svn_fs__dag_merge (which I
thought will do the underlying work of svn_fs_merge) in my
previous patch. You need to lock DB before commiting to
ensure no changes are lost, so you need merge function which
takes trail as argument if you do internal merge. If it
fails, you just return conflict error. If it succeeds, you
make nodes immutable and stable. I really don't understand
what was wrong with my patch and why you're reinventing all
this. :-(

-- 
Yoshiki Hayashi