Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> If #2 is true, every fs revisions correspond to root node
> revision ID. Unless there are braches, fs revision 1
> corresponds to rnode ID 0.1, 2 to 0.2 and so on. Even if
> there are brahces, you can map fs revision 1.1 to root node
> revision ID 0.1.1 if you loosen the rule of fs revision to
> be integers. So why is it necessary to keep separate table
> to manage fs revisions? I don't see why fs revision have
> proplist since root node already has one.
Consider the case where you have several people building transactions
simultaneously. Every transaction's root node is a successor of some
revision of the root directory, but the filesystem has no way of
knowing which transaction will be committed first, so it can't assign
the preferred node revision ID 0.R to the "right" one.
Revisions also have their own properties, distinct from the root
directory's properties. The log message is a property of the
revision, not the root directory.
Received on Sat Oct 21 14:36:22 2006