Re: How can svn_fs_abort_txn be implemented?

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> > There's an argument for making the nodes immutable when
> > close_file is called. You can't do it or you won't be able
> > to distinguish which nodes were created in that transaction.
>
> Yes, you can. Any mutable node reachable from a transaction root
> belongs to that transaction only. Mutable nodes are always private to
> the transaction they were created in; they never appear in more than
> one transaction's tree. So you just start from the transaction's
> root, and delete nodes until you hit mutable nodes.
                                       ^^^^^^^ immutable?

Sorry, I don't understand the first sentence. I also don't
understand last sentence as it is, so it might be better to
state how I think it works.

Say fs revision 10 has following structure (number below
each path component represents node revision ID and M means
the node is mutable):

/project/subversion/subversion/libsvn_fs/dag.c
 (0.8) (1.6) (2.4) (3.4) (4.3)
                                         dag.h
                                         (5.3)

Then, dag.c is changed in working copy and all the necessary
changes are done except svn_fs_commit_txn() or
svn_fs_abort_txn().

/project/subversion/subversion/libsvn_fs/dag.c
 (0.9) (1.7) (2.5) (3.5) (4.4)
   M M M M M
                                         dag.h
                                         (5.3)

Suppose svn_fs_abort_txn() is called here. You need to
remove revision node ID 0.9, 1.7, 2.5, 3.5, 4.4 from nodes
table or you'll end up having many stray nodes in the table.
Luckily, all these freshly created revisions are mutable and
can be easily distinguished from other already existent node
like dag.h. So what svn_fs_abort_txn() will do is to remove
all mutable nodes reachable from root node of given
transaction.

If you made any node immutable, you'll lose information
about which node is new. If dag.c is marked immutable when
close_file is called, tree will look like:

/project/subversion/subversion/libsvn_fs/dag.c
 (0.9) (1.7) (2.5) (3.5) (4.4)
   M M M M
                                         dag.h
                                         (5.3)

Here, you can't tell dag.c or dag.h is created in this
transaction unless you record every new node revision IDs in
another table. If svn_fs_abort_txn() is called, dag.c(4.4)
and dag.h(5.3) remain in nodes table, dag.c(4.4) being
referenced from nowhere. Therefore, you can't make any
mutable nodes immutable before svn_commit_txn() takes place.

Is this view correct?

-- 
Yoshiki Hayashi