On Mon, 2004-03-29 at 21:51, Greg Hudson wrote:
> Okay, enough about requirements. Here is my current design plan, from
> a thousand feet up:
>
> * Finished revisions are represented as a single file.
>
> * Node-revisions are located by a revision number and an offset in
> the revision file. (However, the revision file format will be
> plain text.)
>
> * All delta arrows point backwards in time, as opposed to our
> current ones which point forwards. Thus, a revision file never
> needs to be changed once it has been put into place. Skip-deltas
> and the delta-combiner ensure that we only need to read O(lg(n))
> deltas and combine them together in order to regenerate any given
> plaintext.
>
> * Transactions which have yet to be committed are represented as one
> file for the changed-file data (appended to as changed files come
> in) and a directory tree mirroring the changed part of the
> transaction.
>
> * To prepare for a commit, we perform the auto-merge, grab a write
> lock on the repository, marshal the changed-directory data onto
> the end of the changed-file file, and move the new file into
> place.
My initial gut reaction: I find this overview very clever. I'm really
curious about the proposed single-file format to hold an entire
revision. There's a bit of hand-waving going on here: this file would
have to contain a whole tree structure plus multiple node-revs, and each
node-rev would have to contain text and prop-deltas. I wonder: would
this magical file format look something like a version-3 dumpfile? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 17:59:17 2004