Imported from /home/lorry/working-area/delta_cvs-tarball/cvs-1.12.13.tar.bz2.HEADcvs-1.12.13master

1 files changed, 853 insertions, 0 deletions

diff --git a/TODO b/TODO
new file mode 100644
index 0000000..783bf60
--- /dev/null
+++ b/TODO
@@ -0,0 +1,853 @@
+The "TODO" file!                              -*-Indented-Text-*-
+
+38. Think hard about using RCS state information to allow one to checkin
+    a new vendor release without having it be accessed until it has been
+    integrated into the local changes.
+
+39. Think about a version of "cvs update -j" which remembers what from
+    that other branch is already merged.  This has pitfalls--it could
+    easily lead to invisible state which could confuse users very
+    rapidly--but having to create a tag or some such mechanism to keep
+    track of what has been merged is a pain.  Take a look at PRCS 1.2.
+    PRCS 1.0 was particularly bad the way it handled the "invisible
+    state", but 1.2 is significantly better.
+
+52. SCCS has a feature that I would *love* to see in CVS, as it is very
+    useful.  One may make a private copy of SCCS suid to a particular user,
+    so other users in the authentication list may check files in and out of
+    a project directory without mucking about with groups.  Is there any
+    plan to provide a similar functionality to CVS?  Our site (and, I'd
+    imagine, many other sites with large user bases) has decided against
+    having the user-groups feature of unix available to the users, due to
+    perceived administrative, technical and performance headaches.  A tool
+    such as CVS with features that provide group-like functionality would
+    be a huge help.
+
+62. Consider using revision controlled files and directories to handle the
+    new module format -- consider a cvs command front-end to
+    add/delete/modify module contents, maybe.
+
+63. The "import" and vendor support commands (co -j) need to be documented
+    better.
+
+66. Length of the CVS temporary files must be limited to 14 characters for
+    System-V stupid support.  As well as the length on the CVS.adm files.
+
+72. Consider re-design of the module -t options to use the file system more
+    intuitively.
+
+73. Consider an option (in .cvsrc?) to automatically add files that are new
+    and specified to commit.
+
+79. Might be nice to have some sort of interface to Sun's Translucent
+    (?) File System and tagged revisions.
+
+82. Maybe the import stuff should allow an arbitrary revision to be
+    specified.
+
+84. Improve the documentation about administration of the repository and
+    how to add/remove files and the use of symbolic links.
+
+85. Make symbolic links a valid thing to put under version control.
+    Perhaps use one of the tag fields in the RCS file?  Note that we
+    can only support symlinks that are relative and within the scope of
+    the sources being controlled.
+
+93. Need to think hard about release and development environments.  Think
+    about execsets as well.
+
+98. If diff3 bombs out (too many differences) cvs then thinks that the file
+    has been updated and is OK to be commited even though the file 
+    has not yet been merged.
+
+100. Checked out files should have revision control support.  Maybe.
+
+102. Perhaps directory modes should be propagated on all import check-ins.
+     Not necessarily uid/gid changes.
+
+103. setuid/setgid on files is suspect.
+
+104. cvs should recover nicely on unreadable files/directories.
+
+105. cvs should have administrative tools to allow for changing permissions
+     and modes and what not.  In particular, this would make cvs a
+     more attractive alternative to rdist.
+
+107. It should be possible to specify a list of symbolic revisions to
+     checkout such that the list is processed in reverse order looking for
+     matches within the RCS file for the symbolic revision.  If there is
+     not a match, the next symbolic rev on the list is checked, and so on,
+     until all symbolic revs are exhausted.  This would allow one to, say,
+     checkout "4.0" + "4.0.3" + "4.0.3Patch1" + "4.0.3Patch2" to get the
+     most recent 4.x stuff.  This is usually handled by just specifying the
+     right release_tag, but most people forget to do this.
+
+108. If someone creates a whole new directory (i.e. adds it to the cvs
+     repository) and you happen to have a directory in your source farm by
+     the same name, when you do your cvs update -d it SILENTLY does
+     *nothing* to that directory.  At least, I think it was silent;
+     certainly, it did *not* abort my cvs update, as it would have if the
+     same thing had happened with a file instead of a directory.
+
+109. I had gotten pieces of the sys directory in the past but not a
+     complete tree.  I just did something like:
+
+        cvs get *
+
+     Where sys was in * and got the message
+
+        cvs get: Executing 'sys/tools/make_links sys'
+        sh: sys/tools/make_links: not found
+
+     I suspect this is because I didn't have the file in question,
+     but I do not understand how I could fool it into getting an
+     error.  I think a later cvs get sys seemed to work so perhaps
+     something is amiss in handling multiple arguments to cvs get?
+
+119. When importing a directory tree that is under SCCS/RCS control,
+     consider an option to have import checkout the SCCS/RCS files if
+     necessary.  (This is if someone wants to import something which
+     is in RCS or SCCS without preserving the history, but makes sure
+     they do get the latest versions.  It isn't clear to me how useful
+     that is -kingdon, June 1996).
+
+122. If Name_Repository fails, it currently causes CVS to die completely.  It
+     should instead return NULL and have the caller do something reasonable
+     (???  -what is reasonable?  I'm not sure there is a real problem here.
+     -kingdon, June 1996).
+
+123. Add a flag to import to not build vendor branches for local code.
+     (See `importb' tests in src/sanity.sh for more details).
+
+124. Anyway, I thought you might want to add something like the following
+     to the cvs man pages:
+
+     BUGS
+ 	The sum of the sizes of a module key and its contents are
+ 	limited.  See ndbm(3).
+
+126. Do an analysis to see if CVS is forgetting to close file descriptors.
+     Especially when committing many files (more than the open file limit
+     for the particular UNIX).
+
+127. Look at *info files; they should all be quiet if the files are not
+     there.  Should be able to point at a RCS directory and go.
+
+130. cvs diff with no -r arguments does not need to look up the current RCS
+     version number since it only cares about what's in the Entries file.
+     This should make it much faster.
+
+     It should ParseEntries itself and access the entries list much like
+     Version_TS does (sticky tags and sticky options may need to be
+     supported here as well).  Then it should only diff the things that
+     have the wrong time stamp (the ones that look modified).
+
+134. Make a statement about using hard NFS mounts to your source
+     repository.  Look into checking NULL fgets() returns with ferror() to
+     see if an error had occurred.  (we should be checking for errors, quite
+     aside from NFS issues -kingdon, June 1996).
+
+137. Some sites might want CVS to fsync() the RCS ,v file to protect
+     against nasty hardware errors.  There is a slight performance hit with
+     doing so, though, so it should be configurable in the .cvsrc file.
+     Also, along with this, we should look at the places where CVS itself
+     could be a little more synchronous so as not to lose data.
+     [[ I've done some of this, but it could use much more ]]
+
+138. Some people have suggested that CVS use a VPATH-like environment
+     variable to limit the amount of sources that need to be duplicated for
+     sites with giant source trees and no disk space.
+
+141. Import should accept modules as its directory argument.  If we're
+     going to implement this, we should think hard about how modules
+     might be expanded and how to handle those cases.
+
+143. Update the documentation to show that the source repository is
+     something far away from the files that you work on.  (People who
+     come from an RCS background are used to their `repository' being
+     _very_ close to their working directory.)
+
+144. Have cvs checkout look for the environment variable CVSPREFIX
+     (or CVSMODPREFIX or some such).  If it's set, then when looking
+     up an alias in the modules database, first look it up with the
+     value of CVSPREFIX attached, and then look for the alias itself.
+     This would be useful when you have several projects in a single
+     repository.  You could have aliases abc_src and xyz_src and
+     tell people working on project abc to put "setenv CVSPREFIX abc_"
+     in their .cshrc file (or equivalent for other shells).
+     Then they could do "cvs co src" to get a copy of their src
+     directory, not xyz's.  (This should create a directory called
+     src, not abc_src.)
+
+145. After you create revision 1.1.1.1 in the previous scenario, if
+     you do "cvs update -r1 filename" you get revision 1.1, not
+     1.1.1.1.  It would be nice to get the later revision.  Again,
+     this restriction comes from RCS and is probably hard to
+     change in CVS.  Sigh.
+
+     |"cvs update -r1 filename" does not tell RCS to follow any branches.  CVS
+     |tries to be consistent with RCS in this fashion, so I would not change
+     |this.  Within CVS we do have the flexibility of extending things, like
+     |making a revision of the form "-r1HEAD" find the most recent revision
+     |(branch or not) with a "1." prefix in the RCS file.  This would get what
+     |you want maybe.
+      
+     This would be very useful.  Though I would prefer an option
+     such as "-v1" rather than "-r1HEAD".  This option might be
+     used quite often.
+
+146. The merging of files should be controlled via a hook so that programs
+     other than "rcsmerge" can be used, like Sun's filemerge or emacs's
+     emerge.el.  (but be careful in making this work client/server--it means
+     doing the interactive merging at the end after the server is done).
+     (probably best is to have CVS do the non-interactive part and
+     tell the user about where the files are (.#foo.c.working and
+     .#foo.c.1.5 or whatever), so they can do the interactive part at
+     that point -kingdon, June 1996).
+
+149. Maybe there should be an option to cvs admin that allows a user to
+     change the Repository/Root file with some degree of error checking?
+     Something like "cvs admin reposmv /old/path /new/pretty/path".  Before
+     it does the replace it check to see that the files
+     /new/pretty/path/<dir>/<files> exist.
+
+     The obvious cases are where one moves the repository to another
+     machine or directory.  But there are other cases, like where the
+     user might want to change from :pserver: to :ext:, use a different
+     server (if there are two server machines which share the
+     repository using a networked file system), etc.
+
+     The status quo is a bit of a mess (as of, say, CVS 1.9).  It is
+     that the -d global option has two moderately different uses.  One
+     is to use a totally different repository (in which case we'd
+     probably want to give an error if it disagreed with CVS/Root, as
+     CVS 1.8 and earlier did).  The other is the "reposmv"
+     functionality above (in which the two repositories really are the
+     same, and we want to update the CVS/Root files).  In CVS 1.9 and
+     1.10, -d rewrites the CVS/Root file (but not in subdirectories).
+     This behavior was not particularly popular and has been since
+     reverted.
+
+     This whole area is a rather bad pile of individual decisions which
+     accumulated over time, some of them probably bad decisions with
+     hindsight.  But we didn't get into this mess overnight, and we're
+     not going to get out of it overnight (that is, we need to come up
+     with a replacement behavior, document what parts of the status
+     quo are deprecated, probably circulate some unofficial patches, &c).
+
+     (this item originally added 2 Feb 1992 but revised since).
+
+150. I have a customer request for a way to specify log message per
+     file, non-interactively before the commit, such that a single, fully
+     recursive commit prompts for one commit message, and concatenates the
+     per file messages for each file.  In short, one commit, one editor
+     session, log messages allowed to vary across files within the commit.
+     Also, the per file messages should be allowed to be written when the
+     files are changed, which may predate the commit considerably.
+
+     A new command seems appropriate for this.  The state can be saved in the
+     CVS directory.  I.e.,
+
+        % cvs message foo.c
+        Enter log message for foo.c
+        >> fixed an uninitialized variable
+        >> ^D
+
+     The text is saved as CVS/foo.c,m (or some such name) and commit
+     is modified to append (prepend?) the text (if found) to the log
+     message specified at commit time.  Easy enough.  (having cvs
+     commit be non-interactive takes care of various issues like
+     whether to connect to the server before or after prompting for a
+     message (see comment in commit.c at call to start_server).  Also
+     would clean up the kludge for what to do with the message from
+     do_editor if the up-to-date check fails (see commit.c client code).
+
+     I'm not sure about the part above about having commit prompt
+     for an overall message--part of the point is having commit
+     non-interactive and somehow combining messages seems like (excess?)
+     hair.
+
+     Would be nice to do this so it allows users more flexibility in
+     specifying messages per-directory ("cvs message -l") or per-tree
+     ("cvs message") or per-file ("cvs message foo.c"), and fixes the
+     incompatibility between client/server (per-tree) and
+     non-client/server (per-directory).
+
+     A few interesting issues with this: (1) if you do a cvs update or
+     some other operation which changes the working directory, do you
+     need to run "cvs message" again (it would, of course, bring up
+     the old message which you could accept)?  Probably yes, after all
+     merging in some conflicts might change the situation.  (2) How do
+     you change the stored messages if you change your mind before the
+     commit (probably run "cvs message" again, as hinted in (1))?
+
+151. Also, is there a flag I am missing that allows replacing Ulrtx_Build
+     by Ultrix_build?  I.E. I would like a tag replacement to be a one step
+     operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build"
+     followed by "cvs rtag -d Ulrtx_Build"
+
+152. The "cvs -n" option does not work as one would expect for all the
+     commands.  In particular, for "commit" and "import", where one would
+     also like to see what it would do, without actually doing anything.
+
+153. There should be some command (maybe I just haven't figured out
+     which one...) to import a source directory which is already
+     RCS-administered without losing all prior RCS gathered data.
+     Thus, it would have to examine the RCS files and choose a
+     starting version and branch higher than previous ones used.
+     (Check out rcs-to-cvs and see if it addresses this issue.)
+
+154. When committing the modules file, a pre-commit check should be done to
+     verify the validity of the new modules file before allowing it to be
+     committed.
+
+155. The options for "cvs history" are mutually exclusive, even though
+     useful queries can be done if they are not, as in specifying both
+     a module and a tag.  A workaround is to specify the module, then
+     run the output through grep to only display lines that begin with
+     T, which are tag lines.  (Better perhaps if we redesign the whole
+     "history" business -- check out doc/cvs.texinfo for the entire
+     rant.)
+
+156. Also, how hard would it be to allow continuation lines in the
+     {commit,rcs,log}info files? It would probably be useful with all of
+     the various flags that are now available, or if somebody has a lot of
+     files to put into a module.
+
+158. If I do a recursive commit and find that the same RCS file is checked
+     out (and modified!) in two different places within my checked-out
+     files (but within the realm of a single "commit"), CVS will commit the
+     first change, then overwrite that change with the second change.  We
+     should catch this (typically unusual) case and issue an appropriate
+     diagnostic and die.
+
+160. The checks that the commit command does should be extended to make
+     sure that the revision that we will lock is not already locked by
+     someone else.  Maybe it should also lock the new revision if the old
+     revision was already locked by the user as well, thus moving the lock
+     forward after the commit.
+
+163. The rtag/tag commands should have an option that removes the specified
+     tag from any file that is in the attic.  This allows one to re-use a
+     tag (like "Mon", "Tue", ...) all the time and still have it tag the
+     real main-line code.
+
+165. The "import" command will create RCS files automatically, but will
+     screw-up when trying to create long file names on short file name
+     file systems.  Perhaps import should be a bit more cautious.
+
+166. There really needs to be a "Getting Started" document which describes
+     some of the new CVS philosophies.  Folks coming straight from SCCS or
+     RCS might be confused by "cvs import".  Also need to explain:
+		- How one might setup their $CVSROOT
+		- What all the tags mean in an "import" command
+		- Tags are important; revision numbers are not
+
+170. Is there an "info" file that can be invoked when a file is checked out, or
+     updated ?  What I want to do is to advise users, particularly novices, of
+     the state of their working source whenever they check something out, as
+     a sanity check.
+ 
+     For example, I've written a perl script which tells you what branch you're
+     on, if any.  Hopefully this will help guard against mistaken checkins to
+     the trunk, or to the wrong branch.  I suppose I can do this in
+     "commitinfo", but it'd be nice to advise people before they edit their
+     files.
+  
+     It would also be nice if there was some sort of "verboseness" switch to
+     the checkout and update commands that could turn this invocation of the
+     script off, for mature users.
+
+173. Need generic date-on-branch handling.  Currently, many commands
+     allow both -r and -D, but that's problematic for commands like diff
+     that interpret that as two revisions rather than a single revision.
+     Checkout and update -j takes tag:date which is probably a better
+     solution overall.
+
+174. I would like to see "cvs release" modified so that it only removes files
+     which are known to CVS - all the files in the repository, plus those which
+     are listed in .cvsignore.  This way, if you do leave something valuable in
+     a source tree you can "cvs release -d" the tree and your non-CVS goodies
+     are still there.  If a user is going to leave non-CVS files in their source
+     trees, they really should have to clean them up by hand.
+
+175. And, in the feature request department, I'd dearly love a command-line
+     interface to adding a new module to the CVSROOT/modules file.
+
+176. If you use the -i flag in the modules file, you can control access
+     to source code; this is a Good Thing under certain circumstances. I
+     just had a nasty thought, and on experiment discovered that the
+     filter specified by -i is _not_ run before a cvs admin command; as
+     this allows a user to go behind cvs's back and delete information
+     (cvs admin -o1.4 file) this seems like a serious problem.
+
+177. We've got some external vendor source that sits under a source code
+     hierarchy, and when we do a cvs update, it gets wiped out because
+     its tag is different from the "main" distribution. I've tried to
+     use "-I" to ignore the directory, as well as .cvsignore, but this
+     doesn't work.
+
+179. "cvs admin" does not log its actions with loginfo, nor does it check
+     whether the action is allowed with commitinfo.  It should.
+
+182.  There should be a way to show log entries corresponding to
+changes from tag "foo" to tag "bar".  "cvs log -rfoo:bar" doesn't cut
+it, because it erroneously shows the changes associated with the
+change from the revision before foo to foo.  I'm not sure that is ever
+a useful or logical behavior ("cvs diff -r foo -r bar" gets this
+right), but is compatibility an issue?  See
+http://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch.
+
+183.  "cvs status" should report on Entries.Static flag and CVS/Tag (how?
+maybe a "cvs status -d" to give directory status?).  There should also
+be more documentation of how these get set and how/when to re-set them.
+
+184.  Would be nice to implement the FreeBSD MD5-based password hash
+algorithm in pserver.  For more info see "6.1. DES, MD5, and Crypt" in
+the FreeBSD Handbook, and src/lib/libcrypt/crypt.c in the FreeBSD
+sources.  Certainly in the context of non-unix servers this algorithm
+makes more sense than the traditional unix crypt() algorithm, which
+suffers from export control problems.
+
+185.  A frequent complaint is that keyword expansion causes conflicts
+when merging from one branch to another.  The first step is
+documenting CVS's existing features in this area--what happens with
+various -k options in various places?  The second step is thinking
+about whether there should be some new feature and if so how it should
+be designed.  For example, here is one thought:
+
+    rcs' co command needs a new -k option.  The new option should expand
+    $Log entries without expanding $Revision entries.  This would
+    allow cvs to use rcsmerge in such a way that joining branches into
+    main lines would neither generate extra collisions on revisions nor
+    drop log lines.
+
+The details of this are out of date (CVS no longer invokes "co", and
+any changes in this area would be done by bypassing RCS rather than
+modifying it), but even as to the general idea, I don't have a clear
+idea about whether it would be good (see what I mean about the need
+for better documentation?  I work on CVS full-time, and even I don't
+understand the state of the art on this subject).
+
+186.  There is a frequent discussion of multisite features.
+
+* There may be some overlap with the client/server CVS, which is good
+especially when there is a single developer at each location.  But by
+"multisite" I mean something in which each site is more autonomous, to
+one extent or another.
+
+* Vendor branches are the closest thing that CVS currently has for
+multisite features.  They have fixable drawbacks (such as poor
+handling of added and removed files), and more fundamental drawbacks
+(when you import a vendor branch, you are importing a set of files,
+not importing any knowledge of their version history outside the
+current repository).
+
+* One approach would be to require checkins (or other modifications to
+the repository) to succeed at a write quorum of sites (51%) before
+they are allowed to complete.  To work well, the network should be
+reliable enough that one can typically get to that many sites.  When a
+server which has been out of touch reconnects, it would want to update
+its data before doing anything else.  Any of the servers can service
+all requests locally, except perhaps for a check that they are
+up-to-date.  The way this differs from a run-of-the-mill distributed
+database is that if one only allows reversible operations via this
+mechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site
+can back up the others, such that failures at one site, including
+something like deleting all the sources, can be recovered from.  Thus
+the sites need not trust each other as much as for many shared
+databases, and the system may be resilient to many types of
+organizational failures.  Sometimes I call this design the
+"CVScluster" design.
+
+* Another approach is a master/slave one.  Checkins happen at the
+master site, and slave sites need to check whether their local
+repository is up to date before relying on its information.
+
+* Another approach is to have each site own a particular branch.  This
+one is the most tolerant of flaky networks; if checkins happen at each
+site independently there is no particular problem.  The big question
+is whether merges happen only manually, as with existing CVS branches,
+or whether there is a feature whereby there are circumstances in which
+merges from one branch to the other happen automatically (for example,
+the case in which the branches have not diverged).  This might be a
+legitimate question to ask even quite aside from multisite features.
+
+187.  Might want to separate out usage error messages and help
+messages.  The problem now is that if you specify an invalid option,
+for example, the error message is lost among all the help text.  In
+the new regime, the error message would be followed by a one-line
+message directing people to the appropriate help option ("cvs -H
+<command>" or "cvs --help-commands" or whatever, according to the
+situation).  I'm not sure whether this change would be controversial
+(as defined in HACKING), so there might be a need for further
+discussion or other actions other than just coding.
+
+188.  Option parsing and .cvsrc has at least one notable limitation.
+If you want to set a global option only for some CVS commands, there
+is no way to do it (for example, if one wants to set -q only for
+"rdiff").  I am told that the "popt" package from RPM
+(http://www.rpm.org) could solve this and other problems (for example,
+if the syntax of option stuff in .cvsrc is similar to RPM, that would
+be great from a user point of view).  It would at least be worth a
+look (it also provides a cleaner API than getopt_long).
+
+Another issue which may or may not be related is the issue of
+overriding .cvsrc from the command line.  The cleanest solution might
+be to have options in mutually exclusive sets (-l/-R being a current
+example, but --foo/--no-foo is a better way to name such options).  Or
+perhaps there is some better solution.
+
+189.  Renaming files and directories is a frequently discussed topic.
+
+Some of the problems with the status quo:
+
+a.  "cvs annotate" cannot operate on both the old and new files in a
+single run.  You need to run it twice, once for the new name and once
+for the old name.
+
+b.  "cvs diff" (or "cvs diff -N") shows a rename as a removal of the
+old file and an addition of the new one.  Some people would like to
+see the differences between the file contents (but then how would we
+indicate the fact that the file has been renamed?  Certainly the
+notion that "patch(1)" has of renames is as a removal and addition).
+
+c.  "cvs log" should be able to show the changes between two
+tags/dates, even in the presence of adds/removes/renames (I'm not sure
+what the status quo is on this; see also item #182).
+
+d.  Renaming directories is way too hard.
+
+Implementations:
+
+It is perhaps premature to try to design implementation details
+without answering some of the above questions about desired behaviors
+but several general implementations get mentioned.
+
+i.  No fundamental changes (for example, a "cvs rename" command which
+operated on directories could still implement the current recommended
+practice for renaming directories, which is to rename each of the
+files contained therein via an add and a remove).  One thing to note
+that the status quo gets right is proper merges, even with adds and
+removals (Well, mostly right at least.  There are a *LOT* of different
+cases; see the testsuite for some of them).
+
+ii.  Rename database.  In this scheme the files in the repository
+would have some arbitrary name, and then a separate rename database
+would indicate the current correspondence between the filename in the
+working directory and the actual storage.  As far as I know this has
+never been designed in detail for CVS.
+
+iii.  A modest change in which the RCS files would contain some
+information such as "renamed from X" or "renamed to Y".  That is, this
+would be generally similar to the log messages which are suggested
+when one renames via an add and a removal, but would be
+computer-parseable.  I don't think anyone has tried to flesh out any
+details here either.
+
+It is interesting to note that in solution ii. version numbers in the
+"new file" start where the "old file" left off, while in solutions
+i. and iii., version numbers restart from 1.1 each time a file is
+renamed.  Except perhaps in the case where we rename a file from foo
+to bar and then back to foo.  I'll shut up now.
+
+Regardless of the method we choose, we need to address how renames
+affect existing CVS behaviors.  For example, what happens when you
+rename a file on a branch but not the trunk and then try to merge the
+two?  What happens when you rename a file on one branch and delete it
+on another and try to merge the two?
+
+Ideally, we'd come up with a way to parameterize the problem and
+simply write up a lookup table to determine the correct behavior.
+
+190.  The meaning of the -q and -Q global options is very ad hoc;
+there is no clear definition of which messages are suppressed by them
+and which are not.  Here is a classification of the current meanings
+of -q; I don't know whether anyone has done a similar investigation of
+-Q:
+
+  a.  The "warm fuzzies" printed upon entering each directory (for
+  example, "cvs update: Updating sdir").  The need for these messages
+  may be decreased now that most of CVS uses ->fullname instead of
+  ->file in messages (a project which is *still* not 100% complete,
+  alas).  However, the issue of whether CVS can offer status as it
+  runs is an important one.  Of course from the command line it is
+  hard to do this well and one ends up with options like -q.  But
+  think about emacs, jCVS, or other environments which could flash you
+  the latest status line so you can see whether the system is working
+  or stuck.
+
+  b.  Other cases where the message just offers information (rather
+  than an error) and might be considered unnecessarily verbose.  These
+  have a certain point to them, although it isn't really clear whether
+  it should be the same option as the warm fuzzies or whether it is
+  worth the conceptual hair:
+
+    add.c: scheduling %s `%s' for addition (may be an issue)
+    modules.c: %s %s: Executing '%s' (I can see how that might be noise,
+      but...)
+    remove.c: scheduling `%s' for removal (analogous to the add.c one)
+    update.c: Checking out %s (hmm, that message is a bit on the noisy side...)
+      (but the similar message in annotate is not affected by -q).
+
+  c.  Suppressing various error messages.  This is almost surely
+  bogus.
+
+    commit.c: failed to remove tag `%s' from `%s' (Questionable.
+      Rationale might be that we already printed another message
+      elsewhere but why would it be necessary to avoid
+      the extra message in such an uncommon case?)
+    commit.c: failed to commit dead revision for `%s' (likewise)
+    remove.c: file `%s' still in working directory (see below about rm
+      -f analogy)
+    remove.c: nothing known about `%s' (looks dubious to me, especially in
+      the case where the user specified it explicitly).
+    remove.c: removed `%s' (seems like an obscure enough case that I fail
+      to see the appeal of being cryptically concise here).
+    remove.c: file `%s' already scheduled for removal (now it is starting
+      to look analogous to the infamous rm -f option).
+    rtag.c: cannot find tag `%s' in `%s' (more rm -f like behavior)
+    rtag.c: failed to remove tag `%s' from `%s' (ditto)
+    tag.c: failed to remove tag %s from %s (see above about whether RCS_*
+      has already printed an error message).
+    tag.c: couldn't tag added but un-commited file `%s' (more rm -f
+      like behavior)
+    tag.c: skipping removed but un-commited file `%s' (ditto)
+    tag.c: cannot find revision control file for `%s' (ditto, but at first
+      glance seems even worse, as this would seem to be a "can't happen"
+      condition)
+
+191.  Storing RCS files, especially binary files, takes rather more
+space than it could, typically.
+  - The virtue of the status quo is that it is simple to implement.
+    Of course it is also simplest in terms of dealing with compatibility.
+  - Just storing the revisions as separate gzipped files is a common 
+    technique.  It also is pretty simple (no new algorithms, CVS
+    already has zlib around).  Of course for some files (such as files
+    which are already compressed) the gzip step won't help, but
+    something which can at least sometimes avoid rewriting the entire
+    RCS file for each new revision would, I would think, be a big
+    speedup for large files.
+  - Josh MacDonald has written a tool called xdelta which produces
+    differences (that is, sufficient information to transform the old
+    to the new) which looks for common sequences of bytes, like RCS
+    currently does, but which is not based on lines.  This seems to do
+    quite well for some kinds of files (e.g. FrameMaker documents,
+    text files), and not as well for others (anything which is already
+    compressed, executables).  xdelta 1.10 also is faster than GNU diff.
+  - Karl Fogel has thought some about using a difference technique
+    analogous to fractal compression (see the comp.compression FAQ for
+    more on fractal compression, including at least one patent to
+    watch for; I don't know how analogous Karl's ideas are to the
+    techniques described there).
+  - Quite possibly want some documented interface by which a site can
+    plug in their choice of external difference programs (with the
+    ability to choose the program based on filename, magic numbers,
+    or some such).
+
+192.  "cvs update" using an absolute pathname does not work if the
+working directory is not a CVS-controlled directory with the correct
+CVSROOT.  For example, the following will fail:
+
+  cd /tmp
+  cvs -d /repos co foo
+  cd /
+  cvs update /tmp/foo
+
+It is possible to read the CVSROOT from the administrative files in
+the directory specified by the absolute pathname argument to update.
+In that case, the last command above would be equivalent to:
+
+  cd /tmp/foo
+  cvs update .
+
+This can be problematic, however, if we ask CVS to update two
+directories with different CVSROOTs.  Currently, CVS has no way of
+changing CVSROOT mid-stream.  Consider the following:
+
+  cd /tmp
+  cvs -d /repos1 co foo
+  cvs -d /repos2 co bar
+  cd /
+  cvs update /tmp/foo /tmp/bar
+
+To make that example work, we need to think hard about:
+
+  - where and when CVSROOT-related variables get set
+  - who caches said variables for later use
+  - how the remote protocol should be extended to handle sending a new
+    repository mid-stream
+  - how the client should maintain connections to a variety of servers
+    in a single invocation.
+
+Because those issues are hairy, I suspect that having a change in
+CVSROOT be an error would be a better move.
+
+193.  The client relies on timestamps to figure out whether a file is
+(maybe) modified.  If something goes awry, then it ends up sending
+entire files to the server to be checked, and this can be quite slow
+especially over a slow network.  A couple of things that can happen:
+(a) other programs, like make, use timestamps, so one ends up needing
+to do "touch foo" and otherwise messing with timestamps, (b) changing
+the timezone offset (e.g. summer vs. winter or moving a machine)
+should work on unix, but there may be problems with non-unix.
+
+Possible solutions:
+
+   a.  Store a checksum for each file in CVS/Entries or some such
+   place.  What to do about hash collisions is interesting: using a
+   checksum, like MD5, large enough to "never" have collisions
+   probably works in practice (of course, if there is a collision then
+   all hell breaks loose because that code path was not tested, but
+   given the tiny, tiny probability of that I suppose this is only an
+   aesthetic issue).
+
+   b.  I'm not thinking of others, except storing the whole file in
+   CVS/Base, and I'm sure using twice the disk space would be
+   unpopular.
+
+194.  CVS does not separate the "metadata" from the actual revision
+history; it stores them both in the RCS files.  Metadata means tags
+and header information such as the number of the head revision.
+Storing the metadata separately could speed up "cvs tag" enormously,
+which is a big problem for large repositories.  It could also probably
+make CVS's locking much less in the way (see comment in do_recursion
+about "two-pass design").
+
+195.  Many people using CVS over a slow link are interested in whether
+the remote protocol could be any more efficient with network
+bandwidth.  This item is about one aspect of that--how the server
+sends a new version of a file the client has a different version of,
+or vice versa.
+
+a.  Cases in which the status quo already sends a diff.  For most text
+files, this is probably already close to optimal.  For binary files,
+and anomalous (?) text files (e.g. those in which it would help to do
+moves, as well as adds and deletes), it might be worth looking into other
+difference algorithms (see item #191).
+
+b.  Cases in which the status quo does not send a diff (e.g. "cvs
+commit").
+
+b1.  With some frequency, people suggest rsync or a similar algorithm
+(see ftp://samba.anu.edu.au/pub/rsync/).  This could speed things up,
+and in some ways involves the most minimal changes to the default CVS
+paradigm.  There are some downsides though: (1) there is an extra
+network turnaround, (2) the algorithm needs to transmit some data to
+discover what difference type programs can discover locally (although
+this is only about 1% of the size of the files).
+
+b2.  If one is willing to require that users use "cvs edit" before
+editing a file on the client side (in some cases, a development
+environment like emacs can make this fairly easy), then the Modified
+request in the protocol could be extended to allow the client to just
+send differences instead of entire files.  In the degenerate case
+(e.g. "cvs diff" without arguments) the required network traffic is
+reduced to zero, and the client need not even contact the server.
+
+197.  Analyze the difference between CVS_UNLINK & unlink_file.  As far as I
+can tell, unlink_file aborts in noexec mode and CVS_UNLINK does not.  I'm not
+sure it would be possible to remove even the use of temp files in noexec mode,
+but most unlinks should probably be using unlink_file and not CVS_UNLINK.
+
+198.  Remove references to deprecated cvs_temp_name function.
+
+199.  Add test for login & logout functionality, including support for
+backwards compatibility with old CVSROOTs.
+
+200.  Make a 'cvs add' without write access a non-fatal error so that
+the user's Entries file is updated and future 'cvs diffs' will work
+properly.  This should ease patch submission.
+
+201.  cvs_temp_file should be creating temporary files in a privately owned
+subdirectory of of temp due to security issues on some systems.
+
+202.  Enable rdiff to accept most diff options.  Make rdiff output look
+like diff's.  Make CVS diff garbage go to stderr and only standard diff
+output go to stdout.
+
+203.  Add val-tags additions to the tagging code.  Don't remove the
+update additions since val-tags could still be used as a cache when the
+repository was imported from elsewhere (the tags weren't applied with a
+version which wrote val-tags).
+
+204.  Add test case for compression.  A buf_shutdown error using compression
+wasn't caught by the test suite.
+
+205.  There are lots of cases where trailing slashes on directory names
+and other non-canonical paths confuse CVS.  Most of the cases that do
+work are handled on an ad-hoc basis.  We need to come up with a coherent
+strategy to address path canonicalization and apply it consistently.
+
+208.  Merge enhancements to the diff package back into the original GNU source.
+
+209.  Go through this file and try to:
+
+  a.  Verify that items are still valid.
+
+  b.  Create test cases for valid items when they don't exist.
+
+  c.  Remove fixed and no longer applicable items.
+
+210.  Explain to sanity.sh how to deal with paths with spaces and other odd
+characters in them.
+
+211.  Make sanity.sh run under the Win32 bash (cygwin) and maybe other Windex
+environments (e.g. DGSS or whatever the MSVC portability environemnt is called).
+
+212.  Autotestify (see autoconf source) sanity.sh.
+
+213.  Examine desirability of updating the regex library (regex.{c,h}) to the
+more recent versions that come with glibc and emacs.  It might be worth waiting
+for the emacs folks to get their act together and merge their changes into the
+glibc version.
+
+215.  Add reditors and rwatchers commands.
+
+	- Is an r* command abstraction layer possible here for the commands
+	  where this makes sense?  Would it be simpler?  It seems to me the
+	  major operational differences lie in the file list construction.
+
+218.  Fix "checkout -d ." in client/server mode.
+
+221.  Handle spaces in file/directory names.  (Most, if not all, of the
+internal infrastructure already handles them correctly, but most of the
+administrative file interfaces do not.)
+
+223.  Internationalization support.  This probably means using some kind
+of universal character set (ISO 10646?) internally and converting on
+input and output, which opens the locale can of worms.
+
+225.  Add support for --allow-root to server command.
+
+227.  'cvs release' should use the CVS/Root in the directory being released
+when such is specified rather than $CVSROOT.  In my work directory with no CVS
+dir, a release of subdirectories causes the released projects to be tested
+against my $CVSROOT environment variable, which often isn't correct but which
+can complete without generating error messages if the project also exists in
+the other CVSROOT.  This happens a lot with my copies of the ccvs project.
+
+228.  Consider adding -d to commit ala ci.
+
+229.  Improve the locking code to use a random delay with exponential
+backoff ala Ethernet and separate the notification interval from the
+wait interval.
+
+230.  Support for options like compression as part of the CVSROOT might be
+nice.  This should be fairly easy to implement now using the method options.
+
+231.  The `cvs watch off' command needs an extension which enables users in the
+cvsadmin group to turn watch off for users whose logins and email address may
+not exist anymore.
+
+232. Use file descriptor operations exclusively for I/O (not STDIO).
+
+233.  The ls-D-2 test fails when run in the hour transition between daylight
+savings time and standard time.  This probably has something to do with the
+two 1AM to 2AM time slots that occur over that two hour period (one such
+failure was on the morning of October 31st, 2004).
+
+234.  Noop commands should be logged in the history file.  Information can
+still be obtained with noop commands, for instance via `cvs -n up -p', and
+paranoid admins might appreciate this.  Similarly, perhaps diff operations
+should be logged.