Original sources from CVS-1.4A2 munged to fit our directory structure.

1 files changed, 610 insertions, 0 deletions

diff --git a/gnu/usr.bin/cvs/TODO b/gnu/usr.bin/cvs/TODO
new file mode 100644
index 0000000..90795c4
--- /dev/null
+++ b/gnu/usr.bin/cvs/TODO
@@ -0,0 +1,610 @@
+$CVSid: @(#)TODO 1.26 94/09/21 $
+
+01. testing.  An automated testing enviroment would be a big win.
+
+14. Pathname stripper, for checkout, as well as for writing the
+    Repository file.
+    [[ I have a simple one, but need to make sure to call it at all the
+       appropriate points ]]
+
+16. List of current users of a directory needs to be maintained.
+    [[ sort of solved by history database ]]
+
+22. Catch signals for cleanup when "add"ing files.
+
+24. Insist on a log message.
+
+30. Add "patch" program option to the modules database.
+
+31. Think hard about ^C recovery.
+
+35. Add "admin" command as an interface to "rcs".
+    [[ a cheesy version is there, but it should be re-done ]]
+
+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 allowing parallel source trees that can easily track
+    each other.
+    [[ sort of solved with the automagic branch support, but I want more ]]
+
+45. Consider enhancing the "patch" and "tag" command support in the module
+    database -- they seem hard to use since these commands deal directly
+    with the RCS ,v files.
+
+46. Perhaps checkout/checkin/tag/patch commands should be imbedded in the
+    file system directly, using special known command names?
+
+49. cvs xxx commands should be able to deal with files in other
+    directories.  I want to do a cvs ci foo/bar.c.  This complicates things
+    a bit because one might specify files in different directories, but you
+    could just bucket sort them and do everything for each directory
+    together.  Other than that, it's just a matter of using the adm
+    directory from the directory containing the file rather than the cwd.
+    [[ most commands now use the generic recursion processor, but not all;
+    this note is left here to remind me to fix the others ]]
+
+51. a way to identify what files other people are working on.  Imagine "cvs
+    modified", which prints out a table like 
+
+	file	modifiers
+	=====	=========
+	foo.c
+	bar.c	wsd
+	baz.c	nrt jda
+
+    I think this would be pretty difficult; I don't know if this
+    information is stored anywhere.  Also it's hard to say how one gets a
+    user name, maybe a path to their local hierarchy is all you could get.
+    [[ the history stuff does some of this, but not all ]]
+
+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.
+
+53. I'd suggest a way to notify users if/when a file(s) is being worked on.
+    I suggest:
+	+ Always checkout/update files a readonly.
+	+ To work on a file, the user should do:
+		cvs advise filename
+	+ This would maintain their email address associated with that
+	  file name in the repository and change the file mode to writable.
+	+ If other references to that file exist, the registered individuals
+	  are notified via email that another user(s) is going to be working
+	  on same.
+	+ When a committ occurs, the user is automatically 'unadvise'd (the
+	  inverse command should be supported as well) and other's are notified
+	  that a merge will be necessary before their checkin can be
+	  successful.
+
+56. There should be a .cvsrc file that is sourced to customize various
+    variables.  Perhaps there should be a system-wide .cvsrc file that is
+    sourced, then the one in one's home directory, then the environment
+    variables are checked for overriding values.
+
+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.
+
+64. Need to greatly increase the performance of an initial checkout.
+    [[ it got better, then we added functionality, making it worse again ]]
+
+66. Length of the CVS temporary files must be limited to 14 characters for
+    System-V stupid support.  As weel as the length on the CVS.adm files.
+
+67. cvs import should populate the vendor sources with CVS.adm files so
+    that one could use the vendor sources directly without having the check
+    them out.
+
+69. Consider enhacing import to add a module automatically to the module
+    database.  Perhaps with a new option, or perhaps with an editor.
+
+72. Consider re-design of the module -o, -i, -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.
+
+74. Consider adding a way to remove directories/files that you are done
+    with... somehow.
+    [[ cvs release sort of does this ]]
+
+76. Consider adding a layer of abstraction so that CVS can work with both
+    RCS and SCCS files.  Larry says this should be #ifdef'ed.
+
+79. Might be nice to have some sort of interface to TFS 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. Add revision controlled symbolic links to CVS using one of the tag
+    fields in the RCS file.
+
+87. Consider renaming directories and files.
+
+88. Consider using mmap to read files on Sun systems and using a smaller
+    buffer to read files on other systems.  A patch has been supplied.
+
+89. Study the new Dick Grune version of CVS and port any new interesting
+    features to my version of CVS.
+
+91. Better document the format of the source repository and how one might
+    convert their current SCCS or RCS files into CVS format.
+
+92. Look into this:
+	After a bit of soul searching via dbx, I realized my sin was that I'd
+	specified "echo" as the program to call from loginfo. The commit
+	procedure worked fine till it hit my echo, then silently aborted
+	leaving the lockfiles intact. Since I needn't use the loginfo
+	facility, I simply removed those commands and it all works.
+
+93. Need to think hard about release and development environments.  Think
+    about execsets as well.
+
+94. Need to think hard about remote source control and environments
+    together.
+    [[ a contributor has this working over Internet TCP links! ]]
+
+97. Think about some way to undo a change.  This looks hard given the
+    current framework of CVS.
+
+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.
+
+106. Need to figure out how to delete and rename directories from a release
+     and yet have old releases still be accessible.
+
+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?
+
+112. When merging in changes (Glist) and the file ends up exactly as the
+     RCS revision, an "M" is displayed as the "cvs update" output.  This
+     should really just be a "U".  Just an optimization.
+
+113. The "cvs update" command should tee its output to a log file in ".".
+
+114. I wanted to check in my metapreen code tonight, which I had put into
+     a new file called preen.c.  So, recalling your excellent instructions,
+     I typed "cvs add preen.c".  However, cvs complained that there was
+     already a preen.c in /master/etc/fsck/Attic and therefore it wouldn't
+     take mine.  Now what?
+
+115. I still think "cvs modules" is a good idea.
+   Since everything else is inside cvs, "mkmodules" should be in there too:
+
+   Add a "modules" (synonym "mod") command directly in cvs.
+   ("checkout -c" is not really intuitive.  I'd move it into "mod -s".)
+
+   "mod"		Print database as typed. (line count as record id?)
+   "mod -s"		Print the sorted database (as "checkout -c" does now)
+   "mod -m"		Internal replacement for "mkmodules" command.
+   "mod module ..."	Print the raw dbm record for the named modules
+   "mod -p module ..."	Print relative filenames contained in modules.(no ",v")
+   "mod -l module ..."	Prints more info about relative filenames ("ls -l"?)
+   "mod -f file ..."	Tells you what module(s) the filenames are in.
+
+116. The first thing import did was to complain about a missing CVSROOT.adm.
+     How about having "import()" copy some "CVSROOT.adm/{loginfo,modules}"
+     templates into place if it discovers none pointed to by $CVSROOT?  As it
+     stands, one has to hand-craft them.  It would be real nice to have it
+     happen automatically.
+     [[ I hope to add a "cvsinit" command to the installation instructions ]]
+
+119. Consider an option to have import checkout the RCS or SCCS files
+     if necessary.
+
+122. If Name_Repository fails, it currently causes CVS to die completely.  It
+     should instead return NULL and have the caller do something reasonable.
+
+123. Add a flag to import to not build vendor branches for local code.
+
+124. Anyway, I thought you might want to add something like the following
+     to the cvs and mkmodules 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.
+
+128. When I tag a file, the message tells me that I'm tagging a directory.
+
+129. Something strange seems to have happened here.  When I check this out,
+     the update lines (U CFTS/...) seem to report a bogus leading CFTS
+     (e.g. U CFTS/Medusa_TS/...) when the later files are checked out.
+
+     The directory structure doesn't seem to be botched, just the
+     messages.  I don't recall seeing this before.
+
+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.
+
+135. The email CVS sends with each checkin, should include the version
+     number of each file it is checking in.
+     [[ Sort of solved by contrib/log.pl, which does a good job of this ]]
+
+136. Is it possible to specify a command to be run on each file when it is
+     checked out and another command to be run before it is checked in?
+     My idea of how this feature would be used:
+	On checkout:
+		run indent with user's preferred style
+	On checkin:
+		run indent with space-saving, style-free for checkin
+
+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.
+
+139. murf@dingus.sps.mot.com (Steve Murphy) suggests adding a mode where
+     CVS can work across e-mail to a single repository located at some
+     "known" mail address.  The update/commit operations would work through
+     email aliases, causing them to be slow, but would work nonetheless.
+     This could allow for very cheap remote development sites.
+     [[ We may get to TCP connections over the Internet for the next
+     release, but probably won't do an e-mail linkup right away ]]
+
+141. Import should accept modules as its directory argument.
+
+143. Update the documentation to show that the source repository is
+     something far away from the files that you work on.
+
+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.
+
+148. It would be nice if cvs import (and perhaps commit when the rcs file
+     is created) would set the comment leader automagically to the prefix
+     string of $Log entry, if some option is given.  For example, if a file
+     has a line `%*&# $Log...'  the comment leader would be set to `%*&# '.
+     It would help a lot for unknown files with unknown suffix, and if the
+     comment leader is not standard.  Perhaps for cvs 1.4.
+
+149. On Sun, 2 Feb 92 22:01:38 EST, rouilj@dl5000.bc.edu (John P. Rouillard)
+     said:
+     Maybe there should be an option to cvs admin that allows a user to
+     change the Repository 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.
+
+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 msg 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.
+
+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 trag -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.
+
+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.  This could easily be done by adding an option to mkmodules
+     to perform the verification.
+
+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.
+
+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.
+
+157. The "cvs release" command does not understand about module names with
+     the same flexibility that the "checkout" and "rdiff" commands do.
+     It should, though, since it's confusing right now.
+
+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.
+
+159. On "update", when a merge is done, CVS should remember that your file
+     was merged into and should keep reminding you of this fact until you
+     actually look at the file (change its access time).  Once you do this,
+     it should go back to being a normal, unmodified file.  This way, after
+     a big update, you can run update again to see which files just got
+     merged and may need attention.
+
+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.
+
+161. The date parser included with CVS (lib/getdate.y) does not support
+     such RCS-supported dates as "1992/03/07".  It probably should.
+
+162. We have had a number of cases where some idiot does a "cd" into $CVSROOT
+     and tries to run checkout.  I suggest you make it impossible for someone
+     to check out anything directly into $CVSROOT.  This works (though there
+     is no error checking):
+ 
+	getwd(curdir);
+	chdir(getenv("CVSROOT"));
+	getwd(cvsrootdir);
+	strcat(cvsrootdir, "/");
+	chdir(curdir);
+ 
+ 	if (!strncmp (curdir, cvsrootdir, strlen(cvsrootdir))) {
+		abort with a nasty message about writing into the repository.
+	}
+
+     (In other words, if the real path where $CVSROOT is stored is a parent of
+     the real pathname of your current directory, die horribly.)
+
+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.
+
+164. The rcsinfo file should be able to expand environment variables to
+     find the pathname to the template file.  Perhaps it should just
+     popen("cat <line>"); and read the resulting output, to let the shell
+     do the dirty work.
+
+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
+
+167. "cvs log" doesn't understand about CVS magic branch numbers.  As such,
+     the command:
+
+		cvs log -r1.63.2
+		cvs log -rC2
+
+     where "C2" is a magic branch that resolves to 1.63.2 do not print the
+     same things.  Sigh.
+
+168. After making changes to a set of files, some of which were in
+     sub-directories, I wanted to build a patch file for the whole works:
+ 
+        cvs diff -c -rPROD-REL .
+ 
+     However, any diffs for files in sub-directories did not have relative
+     pathnames.  For example, with local changes to perl's hints/aix_rs.sh:
+ 
+        ===================================================================
+        RCS file: /local/src-CVS/misc/perl/hints/aix_rs.sh,v
+        retrieving revision 1.1.1.1
+        diff -c -r1.1.1.1 aix_rs.sh
+        *** 1.1.1.1     1992/12/17 19:43:32
+        --- aix_rs.sh   1993/01/05 21:33:12
+        ***************
+        *** 1,3 ****
+ 
+     It was easy enough to fix in this case, but I'd suggest that the file
+     name have the relative directory prepended and a proper patch "Index:"
+     line be added, such as this:
+ 
+        ===================================================================
+        RCS file: /local/src-CVS/misc/perl/hints/aix_rs.sh,v
+        retrieving revision 1.1.1.1
+        diff -c -r1.1.1.1 hints/aix_rs.sh
+        Index: hints/aix_rs.sh
+        *** 1.1.1.1     1992/12/17 19:43:32
+        --- hints/aix_rs.sh     1993/01/05 21:33:12
+        ***************
+        *** 1,3 ****
+
+169. We are using CVS as the configuration control for a software reuse library.
+     What we do is do system calls passing the needed arguments. In the next
+     release, it would be nice to see an option to put cvs .o files into a
+     archive library with an API. This enhancement would go nicely with the
+     notion of being able to integrate tools into a large software engineering
+     environment.
+
+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.
+
+171. We have been actively using CVS since September, and we still have the
+     opinion that automerge is dangerous.  We have been burned by it a
+     couple of times so far, when people missed the notification of a
+     conflict during an update, and then they committed the files with the
+     >>>>>>> and <<<<<<< reports in them.  This kind of problem usually gets
+     noticed before commit in compiled files when the compiler croaks, but
+     we also maintain many documentation files in CVS, and in one case the
+     problem was not noticed until months later.
+
+172. "cvs add foo/bar" doesn't work, but "cvs remove foo/bar" works. Maybe
+     "cvs add" should be rewritten to use the recursive directory code that
+     most of CVS uses.
+
+173. We have a tagged branch in CVS.  How do we get the version of that branch
+     (for an entire directory) that corresponds to the files on that branch on a
+     certain day?  I'd like to specify BOTH -r and -D to 'cvs checkout', but I
+     can't.  It looks like I can only specify the date for the main line (as
+     opposed to any branches).  True?  Any workarounds to get what I need?
+
+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.
+
+178. At our site we tag all releases of the sw with
+     product name and version number, the tag is pretty
+     long and if you by accident write an old tag which
+     was in use on an old release, the default behaviour
+     of cvs is to change the old tag!!!
+
+     Could the CVS system reject to reuse an old tag?
+     You have the possibility to manually remove it,
+     but you will not have to be afraid of one tag
+     silently changing.
+
+179. "cvs admin" does not log its actions with loginfo, nor does it check
+     whether the action is allowed with commitinfo.  It should.