Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> 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. :-(
I've taken another look. Yoshiki, the reason I didn't go with that
patch was that it had no code related to merging in it (the word
"merge" doesn't even appear anywhere in the patch).
I understand what you're saying above, though -- that it's possible to
write most of the code for commit_txn without having the merge code,
and that the trail will take care of DB txn issues. And I now see why
there needs to be an svn_fs__dag_merge() doing the underlying work of
svn_fs_merge(). :-) So I will finish up the merging stuff right now,
then try redoing commit_txn based on your patch, fitting in the
merging code as you describe above.
Thanks,
-Karl
Received on Sat Oct 21 14:36:25 2006