diff options
Diffstat (limited to 'usr.bin/cvs/TODO')
| -rw-r--r-- | usr.bin/cvs/TODO | 66 |
1 files changed, 0 insertions, 66 deletions
diff --git a/usr.bin/cvs/TODO b/usr.bin/cvs/TODO deleted file mode 100644 index 2d475f2a79c..00000000000 --- a/usr.bin/cvs/TODO +++ /dev/null @@ -1,66 +0,0 @@ -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. |