22. Catch signals for cleanup when "add"ing files. 24. Insist on a log message. (If done, this should be configurable via commitinfo or some new config file -kingdon, Jun 1995). 30. Add "patch" program option to the modules database. 31. Think hard about ^C recovery. 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. 45. Consider enhancing the "rdiff" and "tag" (rtag??) command support in the module database -- they seem hard to use since these commands deal directly with the RCS ,v files. 49. cvs xxx commands should be able to deal with files in other directories. I want to do a cvs add foo/bar.c. [[ most commands now use the generic recursion processor, but not all; this note is left here to remind me to fix the others ]] 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. 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 well as the length on the CVS.adm files. 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. 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. 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. 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? 113. The "cvs update" command should tee its output to a log file in ".". (why? What is wrong with piping stdout to "tee"? -kingdon, Jun 1995) 119. Consider an option to have import checkout the RCS or SCCS files if necessary. (this is if someone want to import something which is in RCS or SCCS without preserving the history, but making 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. 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. 128. When I tag a file, the message tells me that I'm tagging a directory. 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. 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. (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. 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/