Why revisions table is necessary?

[Yoshiki Hayashi <yo...@xemacs.org>]

I think I have better understanding of fs now but I want to
make sure I really understand big picture before I start any
coding.

Here are my understanding of fs revisions:
1. Filesystem revision apply to whole fs, not to a file or to
   a part of tree
2. Every commit bubbles up to root node

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.

Or can fs revisions be applied to part of tree and revisions
table is to record the root of that part?

I think I'm missing something obvious, but I don't know what
it is... I hope I'm not asking a dumb question.

-- 
Yoshiki Hayashi

Re: Why revisions table is necessary?

[Yoshiki Hayashi <yo...@xemacs.org>]

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

> 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.

Thanks Jim, indeed I missed something big.  And thanks for
quick response, Greg.

My last term as undergraduate student finishes tomorrow and
I'll have plenty of time before April, when new term for
graduate school begins.  Fortunately or not, I have to stay
Tokyo during most of vacation.  You can expect some patches
from me.

-- 
Yoshiki Hayashi

Re: Why revisions table is necessary?

[Jim Blandy <ji...@zwingli.cygnus.com>]

Yoshiki Hayashi <yo...@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.