Re: CVS update: subversion/subversion/libsvn_fs dag.c dag.h tree.c txn.c

On Mon, Mar 12, 2001 at 06:28:30PM -0000, kfogel@tigris.org wrote:
> User: kfogel
> Date: 01/03/12 10:28:30
>
> Modified: subversion/libsvn_fs dag.c dag.h tree.c txn.c
> Log:
> Move core of svn_fs_merge into svn_fs__dag_merge. (Next task is to
> try Yoshiki Hayashi's commit_txn, replacing an error return with a
> merge attempt instead.)

I haven't done a full review of this yet, but a little yellow flag is
creeping out. Do we really want to hold a DB transaction open for the
duration of the entire merge?

For example, let's say that we want to do an "optimistic" merge (we are
optimistic that we merge once, and somebody won't create a new rev and mean
we need to merge again). So we go thru and do the full merge. After the
merge is done, then we open a DB transaction and check whether we're still
okay; presuming so, then we stabilize the tree and spin off a new revision.
If we aren't okay (another revision popped into existence), then we loop and
try again.

The intent is to avoid locks as long as possible. We do the bulk of the work
on the assumption it will remain valid.

Now... that said, maybe the code already works that way. I'm not intimate
with it, so I'm just raising a "seems like it should do X. does that seem
right? and does it work that way now?"

thx,
-g

-- 
Greg Stein, http://www.lyra.org/