Branko Čibej <brane@xbc.nu> writes:
> Heh heh, funny you both should mention that...
>
> I have a more general solution in mind to patch the TimeSafe hole we
> currently have. It too involves expanding the meaning of a
> transaction. Currently, our filesystem looks like this
>
> +-----------+ +-----------+
> | revision1 |------>| revision2 |---->...
> +-----------+ +-----------+
> | |
> v v
> +--------------+ +--------------+
> | txnX | | txnY |
> | tree | | tree |
> | txn-props | | txn-props |
> +--------------+ +--------------+
>
> I propose to change this to something that looks like this:
>
> +-----------+ +-----------+
> | revision1 | | revision2 |
> +-----------+ +-----------+
> | ^ | ^
> v | v |
> +------+ +------+
> | txnX |---------------->| txnY |---->...
> +------+ +------+
> | +-------+ | +-------+
> +----->| treeX | +----->| treeY |
> | +-------+ | +-------+
> | +-----------+ | +-----------+
> +----->| txn props | +----->| txn props |
> +-----------+ +-----------+
>
>
> Instead of being an list of immutable revisions, the filesystem would
> become a list of immutable transactions, with revisions (revision
> numbers) becoming nothin but a sparse index into this list.
Revisions already are just sparse indices into the set of
transactions. And "committed" transactions already store their
associated revision number, so you get that bidirectional pointer
relationship between a revision number and a transaction ID (shown in
your "future" ASCII artwork, but not in your "current" view).
Finally, unlike what is implied by your "current" view, revisions
don't contain pointers to each other directly. In fact, transactions
don't even really point to each other directly -- it's the trees
hanging underneath them that have the connections (via node ancestry).
> The point is that when you ask the question, "what did the repository
> look like at time so-and-so", you look for the transaction that was
> committed at that time, and that will link back to the revision
> number.
Greg's proposal already sorta answers the "what did the repository
look like at time so-and-so" because propchanges have timestamps.
Thus, the repository's appearance as of time T is:
Revisions 0 thru youngest as of time T minus propchanges made to
those revisions after time T.
Though, that's admittedly not easily/performantly query-able.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 18:43:46 2005