3 The filesystem needs some path validation stuffs independent of the
4 SVN path utilities. A filesystem path is a well-defined Thing that
5 should be held a safe distance away from future changes to SVN's
11 We must ensure that node numbers are never reused. If we open a node,
12 svn_fs_delete it, and then create new nodes, what happens when the
13 original node structure suddenly comes to refer to an entirely
14 different node? Files become directories?
16 We should convert filenames to some canonical Unicode form, for
19 Does everyone call svn_fs__check_fs who should?
21 svn_fs_delete will actually delete non-empty directories, if they're
22 not cloned. This is inconsistent; should it be fixed?
24 Does every operation on a deleted node or completed transaction fail
27 Produce helpful error messages when filename paths contain null
33 Fix up comments in svn_fs.h for transactions.
35 Add `public name' member to filesystem structure, to use to identify
36 the filesystem in error messages. When driven by DAV, this could be a
39 When a dag function signals an error, it has no idea what the path of
40 the relevant node was. But node revision ID's are pretty useless to
41 the user. tree.c should probably rewrap some errors.
43 svn_fs__getsize shouldn't rely on a maximum value for detecting
46 The use of svn_fs__getsize in svn_fs__parse_id is ugly --- what if
47 svn_vernum_t and apr_size_t aren't the same size?
49 Consider some macros or accessory functions for referencing the pieces
50 of the NODE-REVISION skel (instead of seeing stuff like
51 node->children->next->next and such other unreadable rubbish)
56 We don't store older node revisions as deltas yet.
58 The delta algorithm walks the whole tree using a single pool, so the
59 memory used is proportional to the size of the target tree. Instead,
60 it should use a separate subpool every time it recurses into a new
61 directory, and free that subpool as soon as it's done processing that
62 subdirectory, so the memory used is proportional to the depth of the
65 We should move as much real content out of the NODE-REVISION skel as
66 possible; the skels should be holding only small stuff (node kind,
68 - File contents and deltas should be moved out to a `contents' table.
69 The NODE-REVISION skel should simply contain a key into that table.
70 - Directory contents should be moved out to a `directories' table,
71 with a separate table entry for each directory entry. Keys into the
72 table should be of the form `NODE-ID ENTRY-NAME NODE-REVISION', and
73 values should be node revision ID's, or the word `deleted'; to look
74 up an entry named E in a directory whose node revision is N.R,
75 search for the entry `N E x', where x is the largest number present
77 - Property lists should be moved out to a table `properties', indexed
78 similarly to the above. We could deltify property contents the
79 same way we do file contents.
84 Extend svn_fs_copy to handle mutable nodes.
88 - directory entry cache:
89 Create a cache mapping a node revision id X plus a filename component
90 N onto a new node revision id Y, meaning that X is a directory in
91 which the name N is bound to ID Y. If everything were in the cache,
92 this function could run with no I/O except for the final node.
94 Since node revisions never change, we wouldn't have to worry about
95 invalidating the cache. Mutable node objects will need special
99 If we've recently computed a node's fulltext, we might want to keep
100 that around in case we need to compute one of its nearby ancestors'
101 fulltext, too. This could be a waste, though --- the access
102 patterns are a mix of linear scan (backwards to reconstruct a given
103 revision) and random (who knows what node we'll hit next), so it's
104 not clear what cache policy would be effective. Best to record some
105 data on how many delta applications a given cache would avoid before
109 As people update, we're going to be recomputing text deltas for the
110 most recently changed files pretty often. It might be worthwhile to
111 cache the deltas for a little while.
113 - Handle Unicode canonicalization for directory and property names
114 ourselves. People should be able to hand us any valid UTF-8
115 sequence, perhaps with precomposed characters or non-spacing marks
116 in a non-canonical order, and find the appropriate matches, given
117 the rules defined by the Unicode standard.
119 Keeping repositories alive in the long term: Berkeley DB is infamous
120 for changing its file format from one revision to the next. If someone
121 saves a Subversion 1.0 repository on a CD somewhere, and then tries to
122 read it seven years later, their chance of being able to read it with
123 the latest revision of Subversion is nil. The solution:
125 - Define a simply XML repository dump format for the complete
126 repository data. This should be the same format we use for CVS
127 repository conversion. We'll have an import function.
129 - Write a program that is simple and self-contained --- does not use
130 Berkeley DB, no fancy XML tools, uses nothing but POSIX read and
131 seek --- that can dump a Subversion repository in that format.
133 - For each revision of Subversion, make a sample repository, and
134 archive a copy of it away as test data.
136 - Write a test suite that verifies that the repository dump program
137 can handle all of the archived formats.