I counted one vote for working on a branch (rooneg) and three for
working on the trunk (kfogel, mbk, and maxb), so barring objections, I
will create a trunk/subversion/libsvn_fs_fs directory soon. Initially
it will have no integration with the build system and no way to hook
into the rest of the code base, but there will be reference materials
and some temporary standalone code which need a place to live.
I've come up with a high-level plan for the native-fs-backed-fs layer,
which I hope can facilitate incremental commits as well as parallel
work. It goes thus:
1. Develop a straw-man revision file format. It's not critically
important to get it right on the first try, but it should be
something that we think can efficiently support the libsvn_fs
read APIs, including the ones related to node history.
2. Write code to turn a (standard, not diffy) svn dump into the
proposed file format. This code will not survive the project,
but will allow rapid generation of test cases. At this point,
the code should store everything node-rev contents as plain text,
and it can do stupid things like hold the entire directory
structure of the head revision in memory. It doesn't need to
work incrementally.
3. Write FS code to read, but not write, the file format, under the
assumption that node-revs contain only plain text. Use the tool
from (2) to generate test cases to ensure that the code works.
4. Develop a format for the directory part of mutable transactions.
5. Produce some test case transactions, either using an extension of
the tool from (2) or by hand.
6. Extend the read code from (3) to be able to read from unfinished
transactions as well as from revision files.
7. Write FS code to create and modify unfinished transactions.
It can store node-rev contents in plain text.
8. Write FS code to perform the auto-merge of an unfinished
transaction and any revisions which have occurred since the
transaction was created.
9. Write FS code to commit an unfinished transaction by marshalling
its changed-directory data onto the end of the changed-file data
and moving the resulting file into place.
10. Extend the tool from (2) to write out node-rev contents in delta
form, possibly using the code from (3) to determine the base
contents to diff against.
11. Extend the read code from (3) to handle deltas.
12. Extend the write code from (7) and (9) to generate deltas
instead of plain text. (Or do we use deltas for directories in
the current code? I forget. It may be desirable not to.)
Not every step depends on the previous step, so not everything has to
proceed in order. Also, steps (1) and (2) can happen in parallel with
FS abstraction work. (Really, the whole project could happen in
parallel with FS abstraction work; we could create a branch which rips
out the current libsvn_fs and replaces it with new stuff. But it
would be less convenient to work with and harder to integrate at the
end, so it's probably better to do most or all of the abstraction work
first.)
Comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 22:34:29 2004