← Back to branch summary

~svn/ubuntu/raring/subversion/ppa

« back to all changes in this revision

Viewing changes to subversion/libsvn_fs_base/notes/TODO

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad
  • Date: 2005-12-05 01:26:14 UTC
  • mfrom: (1.1.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20051205012614-qom4xfypgtsqc2xq
Tags: 1.2.3dfsg1-3ubuntu1
Merge with the final Debian release of 1.2.3dfsg1-3, bringing in
fixes to the clean target, better documentation of the libdb4.3
upgrade and build fixes to work with swig1.3_1.3.27.

Show diffs side-by-side

added added

removed removed

Lines of Context:
subversion/libsvn_fs_base/notes/TODO
 
1
What's happening now
 
2
 
 
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
 
6
general path library.
 
7
 
 
8
 
 
9
Incorrectnesses
 
10
 
 
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?
 
15
 
 
16
We should convert filenames to some canonical Unicode form, for
 
17
comparison.
 
18
 
 
19
Does everyone call svn_fs__check_fs who should?
 
20
 
 
21
svn_fs_delete will actually delete non-empty directories, if they're
 
22
not cloned.  This is inconsistent; should it be fixed?
 
23
 
 
24
Does every operation on a deleted node or completed transaction fail
 
25
gracefully?
 
26
 
 
27
Produce helpful error messages when filename paths contain null
 
28
characters.
 
29
 
 
30
 
 
31
Uglinesses
 
32
 
 
33
Fix up comments in svn_fs.h for transactions.
 
34
 
 
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
 
37
URL.
 
38
 
 
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.
 
42
 
 
43
svn_fs__getsize shouldn't rely on a maximum value for detecting
 
44
overflow.
 
45
 
 
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?
 
48
 
 
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)
 
52
 
 
53
 
 
54
Slownesses
 
55
 
 
56
We don't store older node revisions as deltas yet.
 
57
 
 
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
 
63
tree.
 
64
 
 
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,
 
67
flags).
 
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
 
76
  <= R.
 
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.
 
80
 
 
81
 
 
82
Amenities
 
83
 
 
84
Extend svn_fs_copy to handle mutable nodes.
 
85
 
 
86
Long term ideas:
 
87
 
 
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.
 
93
 
 
94
  Since node revisions never change, we wouldn't have to worry about
 
95
  invalidating the cache.  Mutable node objects will need special
 
96
  handling, of course.
 
97
 
 
98
- fulltext cache:
 
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
 
106
  implementing it.
 
107
 
 
108
- delta cache:
 
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.
 
112
 
 
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.
 
118
 
 
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:
 
124
 
 
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.
 
128
 
 
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.
 
132
 
 
133
- For each revision of Subversion, make a sample repository, and
 
134
  archive a copy of it away as test data.
 
135
 
 
136
- Write a test suite that verifies that the repository dump program
 
137
  can handle all of the archived formats.