blob: 2d475f2a79cdf311cb89d69bd4135a9ab61864db (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
OpenCVS 0.2 TODO
Top priority: missing commands
Missing commands (client mode only for now)
================
Implementing the missing commands is mostly a job of copying the code from
the working commands and changing some of the requests to be sent.
Put your name next to it if you are working on a particular command.
Missing commands:
- add
- admin
- annotate
- commit (jfb)
- history?
- log (jfb)
- release
- remove
- status
- tag
- the 'r' commands (rdiff, rlog, rtag)
Merging the common code
=======================
It is becoming quite clear that almost all of the functions share about 90%
of the code that is in cvs_<command>_file(), so we should probably look at
a way to simplify the function by automating certain parts.
Multiple server support
=======================
This is close to working but we need to put something like pre- and post-
recursion handlers for cvs_file_examine() so we can send one command
per root connection instead of one global command at the end.
Date handling
=============
A lot of commands must handle date specs in a whole bunch of different
formats (through the -D argument). I assume we will need a good
chunk of code to support all these formats.
cvsd protocol
=============
Our version of 'cvs server' will not actually perform most of the operations
but it will instead dispatch those to the cvs daemon through a connection
made on a local socket. The cvs daemon will then be able to see if the
operation passes through the ACL and perform any modifications to the
repository. The protocol to talk between cvs and the daemon is not yet
finished.
Entries file caching
====================
Update:
Caching all the entries on /usr/src ate around 22MB of memory so this is
obviously not an option. We have two choices: either we suffer the loss
of performance and reopen the file every time we have to make a modification
to it, or we change the way the file hierarchy is loaded and load subparts of
the tree only when needed instead of doing it all at the beginning.
----
Currently, adding entries in an Entries file involves opening that file,
adding the entry and closing the file. This means that on every new entry,
the file is reparsed and rewritten to disk. We should add some kind of
caching system with reference counts on the Entries files so we don't really
close them but keep them opened for future requests to avoid all the disk I/O.
|
