132785SpeterThe "TODO" file! -*-Indented-Text-*- 232785Speter 317721Speter38. Think hard about using RCS state information to allow one to checkin 417721Speter a new vendor release without having it be accessed until it has been 517721Speter integrated into the local changes. 617721Speter 725839Speter39. Think about a version of "cvs update -j" which remembers what from 825839Speter that other branch is already merged. This has pitfalls--it could 925839Speter easily lead to invisible state which could confuse users very 1025839Speter rapidly--but having to create a tag or some such mechanism to keep 1132785Speter track of what has been merged is a pain. Take a look at PRCS 1.2. 1232785Speter PRCS 1.0 was particularly bad the way it handled the "invisible 1332785Speter state", but 1.2 is significantly better. 1417721Speter 1517721Speter52. SCCS has a feature that I would *love* to see in CVS, as it is very 1617721Speter useful. One may make a private copy of SCCS suid to a particular user, 1717721Speter so other users in the authentication list may check files in and out of 1817721Speter a project directory without mucking about with groups. Is there any 1917721Speter plan to provide a similar functionality to CVS? Our site (and, I'd 2017721Speter imagine, many other sites with large user bases) has decided against 2117721Speter having the user-groups feature of unix available to the users, due to 2217721Speter perceived administrative, technical and performance headaches. A tool 2317721Speter such as CVS with features that provide group-like functionality would 2417721Speter be a huge help. 2517721Speter 2617721Speter62. Consider using revision controlled files and directories to handle the 2717721Speter new module format -- consider a cvs command front-end to 2817721Speter add/delete/modify module contents, maybe. 2917721Speter 3017721Speter63. The "import" and vendor support commands (co -j) need to be documented 3117721Speter better. 3217721Speter 3317721Speter66. Length of the CVS temporary files must be limited to 14 characters for 3417721Speter System-V stupid support. As well as the length on the CVS.adm files. 3517721Speter 36128266Speter72. Consider re-design of the module -t options to use the file system more 37128266Speter intuitively. 3817721Speter 3917721Speter73. Consider an option (in .cvsrc?) to automatically add files that are new 4017721Speter and specified to commit. 4117721Speter 4232785Speter79. Might be nice to have some sort of interface to Sun's Translucent 4332785Speter (?) File System and tagged revisions. 4417721Speter 4517721Speter82. Maybe the import stuff should allow an arbitrary revision to be 4617721Speter specified. 4717721Speter 4817721Speter84. Improve the documentation about administration of the repository and 4917721Speter how to add/remove files and the use of symbolic links. 5017721Speter 5132785Speter85. Make symbolic links a valid thing to put under version control. 5232785Speter Perhaps use one of the tag fields in the RCS file? Note that we 5332785Speter can only support symlinks that are relative and within the scope of 5432785Speter the sources being controlled. 5517721Speter 5617721Speter93. Need to think hard about release and development environments. Think 5717721Speter about execsets as well. 5817721Speter 5917721Speter98. If diff3 bombs out (too many differences) cvs then thinks that the file 6017721Speter has been updated and is OK to be commited even though the file 6117721Speter has not yet been merged. 6217721Speter 6317721Speter100. Checked out files should have revision control support. Maybe. 6417721Speter 6517721Speter102. Perhaps directory modes should be propagated on all import check-ins. 6617721Speter Not necessarily uid/gid changes. 6717721Speter 6817721Speter103. setuid/setgid on files is suspect. 6917721Speter 7017721Speter104. cvs should recover nicely on unreadable files/directories. 7117721Speter 7217721Speter105. cvs should have administrative tools to allow for changing permissions 7317721Speter and modes and what not. In particular, this would make cvs a 7417721Speter more attractive alternative to rdist. 7517721Speter 7617721Speter107. It should be possible to specify a list of symbolic revisions to 7717721Speter checkout such that the list is processed in reverse order looking for 7817721Speter matches within the RCS file for the symbolic revision. If there is 7917721Speter not a match, the next symbolic rev on the list is checked, and so on, 8017721Speter until all symbolic revs are exhausted. This would allow one to, say, 8117721Speter checkout "4.0" + "4.0.3" + "4.0.3Patch1" + "4.0.3Patch2" to get the 8217721Speter most recent 4.x stuff. This is usually handled by just specifying the 8317721Speter right release_tag, but most people forget to do this. 8417721Speter 8517721Speter108. If someone creates a whole new directory (i.e. adds it to the cvs 8617721Speter repository) and you happen to have a directory in your source farm by 8717721Speter the same name, when you do your cvs update -d it SILENTLY does 8817721Speter *nothing* to that directory. At least, I think it was silent; 8917721Speter certainly, it did *not* abort my cvs update, as it would have if the 9017721Speter same thing had happened with a file instead of a directory. 9117721Speter 9217721Speter109. I had gotten pieces of the sys directory in the past but not a 9317721Speter complete tree. I just did something like: 9417721Speter 9517721Speter cvs get * 9617721Speter 9717721Speter Where sys was in * and got the message 9817721Speter 9917721Speter cvs get: Executing 'sys/tools/make_links sys' 10017721Speter sh: sys/tools/make_links: not found 10117721Speter 10217721Speter I suspect this is because I didn't have the file in question, 10317721Speter but I do not understand how I could fool it into getting an 10417721Speter error. I think a later cvs get sys seemed to work so perhaps 10517721Speter something is amiss in handling multiple arguments to cvs get? 10617721Speter 10732785Speter119. When importing a directory tree that is under SCCS/RCS control, 10832785Speter consider an option to have import checkout the SCCS/RCS files if 10932785Speter necessary. (This is if someone wants to import something which 11032785Speter is in RCS or SCCS without preserving the history, but makes sure 11132785Speter they do get the latest versions. It isn't clear to me how useful 11232785Speter that is -kingdon, June 1996). 11317721Speter 11417721Speter122. If Name_Repository fails, it currently causes CVS to die completely. It 11525839Speter should instead return NULL and have the caller do something reasonable 11625839Speter (??? -what is reasonable? I'm not sure there is a real problem here. 11725839Speter -kingdon, June 1996). 11817721Speter 11917721Speter123. Add a flag to import to not build vendor branches for local code. 12032785Speter (See `importb' tests in src/sanity.sh for more details). 12117721Speter 12217721Speter124. Anyway, I thought you might want to add something like the following 12317721Speter to the cvs man pages: 12417721Speter 12517721Speter BUGS 12617721Speter The sum of the sizes of a module key and its contents are 12717721Speter limited. See ndbm(3). 12817721Speter 12917721Speter126. Do an analysis to see if CVS is forgetting to close file descriptors. 13017721Speter Especially when committing many files (more than the open file limit 13117721Speter for the particular UNIX). 13217721Speter 13317721Speter127. Look at *info files; they should all be quiet if the files are not 13417721Speter there. Should be able to point at a RCS directory and go. 13517721Speter 13617721Speter130. cvs diff with no -r arguments does not need to look up the current RCS 13717721Speter version number since it only cares about what's in the Entries file. 13817721Speter This should make it much faster. 13917721Speter 14017721Speter It should ParseEntries itself and access the entries list much like 14117721Speter Version_TS does (sticky tags and sticky options may need to be 14217721Speter supported here as well). Then it should only diff the things that 14317721Speter have the wrong time stamp (the ones that look modified). 14417721Speter 14517721Speter134. Make a statement about using hard NFS mounts to your source 14617721Speter repository. Look into checking NULL fgets() returns with ferror() to 14725839Speter see if an error had occurred. (we should be checking for errors, quite 14825839Speter aside from NFS issues -kingdon, June 1996). 14917721Speter 15017721Speter137. Some sites might want CVS to fsync() the RCS ,v file to protect 15117721Speter against nasty hardware errors. There is a slight performance hit with 15217721Speter doing so, though, so it should be configurable in the .cvsrc file. 15317721Speter Also, along with this, we should look at the places where CVS itself 15417721Speter could be a little more synchronous so as not to lose data. 15517721Speter [[ I've done some of this, but it could use much more ]] 15617721Speter 15717721Speter138. Some people have suggested that CVS use a VPATH-like environment 15817721Speter variable to limit the amount of sources that need to be duplicated for 15917721Speter sites with giant source trees and no disk space. 16017721Speter 16132785Speter141. Import should accept modules as its directory argument. If we're 16232785Speter going to implement this, we should think hard about how modules 16332785Speter might be expanded and how to handle those cases. 16417721Speter 16517721Speter143. Update the documentation to show that the source repository is 16632785Speter something far away from the files that you work on. (People who 16732785Speter come from an RCS background are used to their `repository' being 16832785Speter _very_ close to their working directory.) 16917721Speter 17017721Speter144. Have cvs checkout look for the environment variable CVSPREFIX 17117721Speter (or CVSMODPREFIX or some such). If it's set, then when looking 17217721Speter up an alias in the modules database, first look it up with the 17317721Speter value of CVSPREFIX attached, and then look for the alias itself. 17417721Speter This would be useful when you have several projects in a single 17517721Speter repository. You could have aliases abc_src and xyz_src and 17617721Speter tell people working on project abc to put "setenv CVSPREFIX abc_" 17717721Speter in their .cshrc file (or equivalent for other shells). 17817721Speter Then they could do "cvs co src" to get a copy of their src 17917721Speter directory, not xyz's. (This should create a directory called 18017721Speter src, not abc_src.) 18117721Speter 18217721Speter145. After you create revision 1.1.1.1 in the previous scenario, if 18317721Speter you do "cvs update -r1 filename" you get revision 1.1, not 18417721Speter 1.1.1.1. It would be nice to get the later revision. Again, 18517721Speter this restriction comes from RCS and is probably hard to 18617721Speter change in CVS. Sigh. 18717721Speter 18817721Speter |"cvs update -r1 filename" does not tell RCS to follow any branches. CVS 18917721Speter |tries to be consistent with RCS in this fashion, so I would not change 19017721Speter |this. Within CVS we do have the flexibility of extending things, like 19117721Speter |making a revision of the form "-r1HEAD" find the most recent revision 19217721Speter |(branch or not) with a "1." prefix in the RCS file. This would get what 19317721Speter |you want maybe. 19417721Speter 19517721Speter This would be very useful. Though I would prefer an option 19617721Speter such as "-v1" rather than "-r1HEAD". This option might be 19717721Speter used quite often. 19817721Speter 19917721Speter146. The merging of files should be controlled via a hook so that programs 20017721Speter other than "rcsmerge" can be used, like Sun's filemerge or emacs's 20117721Speter emerge.el. (but be careful in making this work client/server--it means 20217721Speter doing the interactive merging at the end after the server is done). 20325839Speter (probably best is to have CVS do the non-interactive part and 20425839Speter tell the user about where the files are (.#foo.c.working and 20525839Speter .#foo.c.1.5 or whatever), so they can do the interactive part at 20625839Speter that point -kingdon, June 1996). 20717721Speter 20832785Speter149. Maybe there should be an option to cvs admin that allows a user to 20932785Speter change the Repository/Root file with some degree of error checking? 21017721Speter Something like "cvs admin reposmv /old/path /new/pretty/path". Before 21117721Speter it does the replace it check to see that the files 21217721Speter /new/pretty/path/<dir>/<files> exist. 21317721Speter 21432785Speter The obvious cases are where one moves the repository to another 21532785Speter machine or directory. But there are other cases, like where the 21632785Speter user might want to change from :pserver: to :ext:, use a different 21732785Speter server (if there are two server machines which share the 21832785Speter repository using a networked file system), etc. 21932785Speter 22032785Speter The status quo is a bit of a mess (as of, say, CVS 1.9). It is 22132785Speter that the -d global option has two moderately different uses. One 22232785Speter is to use a totally different repository (in which case we'd 22332785Speter probably want to give an error if it disagreed with CVS/Root, as 22432785Speter CVS 1.8 and earlier did). The other is the "reposmv" 22532785Speter functionality above (in which the two repositories really are the 22654427Speter same, and we want to update the CVS/Root files). In CVS 1.9 and 22754427Speter 1.10, -d rewrites the CVS/Root file (but not in subdirectories). 22854427Speter This behavior was not particularly popular and has been since 22954427Speter reverted. 23032785Speter 23132785Speter This whole area is a rather bad pile of individual decisions which 23232785Speter accumulated over time, some of them probably bad decisions with 23332785Speter hindsight. But we didn't get into this mess overnight, and we're 23432785Speter not going to get out of it overnight (that is, we need to come up 23532785Speter with a replacement behavior, document what parts of the status 23632785Speter quo are deprecated, probably circulate some unofficial patches, &c). 23732785Speter 23832785Speter (this item originally added 2 Feb 1992 but revised since). 23932785Speter 24017721Speter150. I have a customer request for a way to specify log message per 24117721Speter file, non-interactively before the commit, such that a single, fully 24217721Speter recursive commit prompts for one commit message, and concatenates the 24317721Speter per file messages for each file. In short, one commit, one editor 24417721Speter session, log messages allowed to vary across files within the commit. 24517721Speter Also, the per file messages should be allowed to be written when the 24617721Speter files are changed, which may predate the commit considerably. 24717721Speter 24817721Speter A new command seems appropriate for this. The state can be saved in the 24917721Speter CVS directory. I.e., 25025839Speter 25125839Speter % cvs message foo.c 25217721Speter Enter log message for foo.c 25317721Speter >> fixed an uninitialized variable 25417721Speter >> ^D 25517721Speter 25625839Speter The text is saved as CVS/foo.c,m (or some such name) and commit 25725839Speter is modified to append (prepend?) the text (if found) to the log 25825839Speter message specified at commit time. Easy enough. (having cvs 25925839Speter commit be non-interactive takes care of various issues like 26025839Speter whether to connect to the server before or after prompting for a 26132785Speter message (see comment in commit.c at call to start_server). Also 26232785Speter would clean up the kludge for what to do with the message from 26332785Speter do_editor if the up-to-date check fails (see commit.c client code). 26417721Speter 26525839Speter I'm not sure about the part above about having commit prompt 26625839Speter for an overall message--part of the point is having commit 26725839Speter non-interactive and somehow combining messages seems like (excess?) 26825839Speter hair. 26925839Speter 27025839Speter Would be nice to do this so it allows users more flexibility in 27125839Speter specifying messages per-directory ("cvs message -l") or per-tree 27225839Speter ("cvs message") or per-file ("cvs message foo.c"), and fixes the 27325839Speter incompatibility between client/server (per-tree) and 27425839Speter non-client/server (per-directory). 27525839Speter 27632785Speter A few interesting issues with this: (1) if you do a cvs update or 27732785Speter some other operation which changes the working directory, do you 27832785Speter need to run "cvs message" again (it would, of course, bring up 27932785Speter the old message which you could accept)? Probably yes, after all 28032785Speter merging in some conflicts might change the situation. (2) How do 28132785Speter you change the stored messages if you change your mind before the 28232785Speter commit (probably run "cvs message" again, as hinted in (1))? 28332785Speter 28417721Speter151. Also, is there a flag I am missing that allows replacing Ulrtx_Build 28517721Speter by Ultrix_build? I.E. I would like a tag replacement to be a one step 28617721Speter operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build" 28732785Speter followed by "cvs rtag -d Ulrtx_Build" 28817721Speter 28917721Speter152. The "cvs -n" option does not work as one would expect for all the 29017721Speter commands. In particular, for "commit" and "import", where one would 29117721Speter also like to see what it would do, without actually doing anything. 29217721Speter 29332785Speter153. There should be some command (maybe I just haven't figured out 29432785Speter which one...) to import a source directory which is already 29532785Speter RCS-administered without losing all prior RCS gathered data. 29632785Speter Thus, it would have to examine the RCS files and choose a 29732785Speter starting version and branch higher than previous ones used. 29832785Speter (Check out rcs-to-cvs and see if it addresses this issue.) 29917721Speter 30017721Speter154. When committing the modules file, a pre-commit check should be done to 30117721Speter verify the validity of the new modules file before allowing it to be 30217721Speter committed. 30317721Speter 30417721Speter155. The options for "cvs history" are mutually exclusive, even though 30532785Speter useful queries can be done if they are not, as in specifying both 30632785Speter a module and a tag. A workaround is to specify the module, then 30732785Speter run the output through grep to only display lines that begin with 30832785Speter T, which are tag lines. (Better perhaps if we redesign the whole 30932785Speter "history" business -- check out doc/cvs.texinfo for the entire 31032785Speter rant.) 31117721Speter 31217721Speter156. Also, how hard would it be to allow continuation lines in the 31317721Speter {commit,rcs,log}info files? It would probably be useful with all of 31417721Speter the various flags that are now available, or if somebody has a lot of 31517721Speter files to put into a module. 31617721Speter 31717721Speter158. If I do a recursive commit and find that the same RCS file is checked 31817721Speter out (and modified!) in two different places within my checked-out 31917721Speter files (but within the realm of a single "commit"), CVS will commit the 32017721Speter first change, then overwrite that change with the second change. We 32117721Speter should catch this (typically unusual) case and issue an appropriate 32217721Speter diagnostic and die. 32317721Speter 32417721Speter160. The checks that the commit command does should be extended to make 32517721Speter sure that the revision that we will lock is not already locked by 32617721Speter someone else. Maybe it should also lock the new revision if the old 32717721Speter revision was already locked by the user as well, thus moving the lock 32817721Speter forward after the commit. 32917721Speter 33017721Speter163. The rtag/tag commands should have an option that removes the specified 33117721Speter tag from any file that is in the attic. This allows one to re-use a 33217721Speter tag (like "Mon", "Tue", ...) all the time and still have it tag the 33317721Speter real main-line code. 33417721Speter 33517721Speter165. The "import" command will create RCS files automatically, but will 33617721Speter screw-up when trying to create long file names on short file name 33717721Speter file systems. Perhaps import should be a bit more cautious. 33817721Speter 33917721Speter166. There really needs to be a "Getting Started" document which describes 34017721Speter some of the new CVS philosophies. Folks coming straight from SCCS or 34117721Speter RCS might be confused by "cvs import". Also need to explain: 34217721Speter - How one might setup their $CVSROOT 34317721Speter - What all the tags mean in an "import" command 34417721Speter - Tags are important; revision numbers are not 34517721Speter 34617721Speter170. Is there an "info" file that can be invoked when a file is checked out, or 34717721Speter updated ? What I want to do is to advise users, particularly novices, of 34817721Speter the state of their working source whenever they check something out, as 34917721Speter a sanity check. 35017721Speter 35117721Speter For example, I've written a perl script which tells you what branch you're 35217721Speter on, if any. Hopefully this will help guard against mistaken checkins to 35317721Speter the trunk, or to the wrong branch. I suppose I can do this in 35417721Speter "commitinfo", but it'd be nice to advise people before they edit their 35517721Speter files. 35617721Speter 35717721Speter It would also be nice if there was some sort of "verboseness" switch to 35817721Speter the checkout and update commands that could turn this invocation of the 35917721Speter script off, for mature users. 36017721Speter 361107484Speter173. Need generic date-on-branch handling. Currently, many commands 362107484Speter allow both -r and -D, but that's problematic for commands like diff 363107484Speter that interpret that as two revisions rather than a single revision. 364107484Speter Checkout and update -j takes tag:date which is probably a better 365107484Speter solution overall. 36617721Speter 36717721Speter174. I would like to see "cvs release" modified so that it only removes files 36817721Speter which are known to CVS - all the files in the repository, plus those which 36917721Speter are listed in .cvsignore. This way, if you do leave something valuable in 37017721Speter a source tree you can "cvs release -d" the tree and your non-CVS goodies 37117721Speter are still there. If a user is going to leave non-CVS files in their source 37217721Speter trees, they really should have to clean them up by hand. 37317721Speter 37417721Speter175. And, in the feature request department, I'd dearly love a command-line 37517721Speter interface to adding a new module to the CVSROOT/modules file. 37617721Speter 37717721Speter176. If you use the -i flag in the modules file, you can control access 37817721Speter to source code; this is a Good Thing under certain circumstances. I 37917721Speter just had a nasty thought, and on experiment discovered that the 38017721Speter filter specified by -i is _not_ run before a cvs admin command; as 38117721Speter this allows a user to go behind cvs's back and delete information 38217721Speter (cvs admin -o1.4 file) this seems like a serious problem. 38317721Speter 38417721Speter177. We've got some external vendor source that sits under a source code 38517721Speter hierarchy, and when we do a cvs update, it gets wiped out because 38617721Speter its tag is different from the "main" distribution. I've tried to 38717721Speter use "-I" to ignore the directory, as well as .cvsignore, but this 38817721Speter doesn't work. 38917721Speter 39017721Speter179. "cvs admin" does not log its actions with loginfo, nor does it check 39117721Speter whether the action is allowed with commitinfo. It should. 39225839Speter 39325839Speter180. "cvs edit" should show you who is already editing the files, 39425839Speter probably (that is, do "cvs editors" before executing, or some 39525839Speter similar result). (But watch out for what happens if the network 39625839Speter is down!). 39725839Speter 39825839Speter182. There should be a way to show log entries corresponding to 39932785Speterchanges from tag "foo" to tag "bar". "cvs log -rfoo:bar" doesn't cut 40032785Speterit, because it erroneously shows the changes associated with the 40132785Speterchange from the revision before foo to foo. I'm not sure that is ever 40232785Spetera useful or logical behavior ("cvs diff -r foo -r bar" gets this 40332785Speterright), but is compatibility an issue? See 40432785Speterhttp://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch. 40525839Speter 40625839Speter183. "cvs status" should report on Entries.Static flag and CVS/Tag (how? 40725839Spetermaybe a "cvs status -d" to give directory status?). There should also 40825839Speterbe more documentation of how these get set and how/when to re-set them. 40925839Speter 41025839Speter184. Would be nice to implement the FreeBSD MD5-based password hash 41125839Speteralgorithm in pserver. For more info see "6.1. DES, MD5, and Crypt" in 41225839Speterthe FreeBSD Handbook, and src/lib/libcrypt/crypt.c in the FreeBSD 41325839Spetersources. Certainly in the context of non-unix servers this algorithm 41425839Spetermakes more sense than the traditional unix crypt() algorithm, which 41525839Spetersuffers from export control problems. 41625839Speter 41725839Speter185. A frequent complaint is that keyword expansion causes conflicts 41825839Speterwhen merging from one branch to another. The first step is 41925839Speterdocumenting CVS's existing features in this area--what happens with 42025839Spetervarious -k options in various places? The second step is thinking 42125839Speterabout whether there should be some new feature and if so how it should 42225839Speterbe designed. For example, here is one thought: 42325839Speter 42425839Speter rcs' co command needs a new -k option. The new option should expand 42525839Speter $Log entries without expanding $Revision entries. This would 42625839Speter allow cvs to use rcsmerge in such a way that joining branches into 42725839Speter main lines would neither generate extra collisions on revisions nor 42825839Speter drop log lines. 42925839Speter 43025839SpeterThe details of this are out of date (CVS no longer invokes "co", and 43125839Speterany changes in this area would be done by bypassing RCS rather than 43225839Spetermodifying it), but even as to the general idea, I don't have a clear 43325839Speteridea about whether it would be good (see what I mean about the need 43425839Speterfor better documentation? I work on CVS full-time, and even I don't 43525839Speterunderstand the state of the art on this subject). 43632785Speter 43732785Speter186. There is a frequent discussion of multisite features. 43832785Speter 43932785Speter* There may be some overlap with the client/server CVS, which is good 44032785Speterespecially when there is a single developer at each location. But by 44132785Speter"multisite" I mean something in which each site is more autonomous, to 44232785Speterone extent or another. 44332785Speter 44432785Speter* Vendor branches are the closest thing that CVS currently has for 44532785Spetermultisite features. They have fixable drawbacks (such as poor 44632785Speterhandling of added and removed files), and more fundamental drawbacks 44732785Speter(when you import a vendor branch, you are importing a set of files, 44832785Speternot importing any knowledge of their version history outside the 44932785Spetercurrent repository). 45032785Speter 45132785Speter* One approach would be to require checkins (or other modifications to 45232785Speterthe repository) to succeed at a write quorum of sites (51%) before 45332785Speterthey are allowed to complete. To work well, the network should be 45432785Speterreliable enough that one can typically get to that many sites. When a 45532785Speterserver which has been out of touch reconnects, it would want to update 45632785Speterits data before doing anything else. Any of the servers can service 45732785Speterall requests locally, except perhaps for a check that they are 45832785Speterup-to-date. The way this differs from a run-of-the-mill distributed 45932785Speterdatabase is that if one only allows reversible operations via this 46032785Spetermechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site 46132785Spetercan back up the others, such that failures at one site, including 46232785Spetersomething like deleting all the sources, can be recovered from. Thus 46332785Speterthe sites need not trust each other as much as for many shared 46432785Speterdatabases, and the system may be resilient to many types of 46532785Speterorganizational failures. Sometimes I call this design the 46632785Speter"CVScluster" design. 46732785Speter 46832785Speter* Another approach is a master/slave one. Checkins happen at the 46932785Spetermaster site, and slave sites need to check whether their local 47032785Speterrepository is up to date before relying on its information. 47132785Speter 47232785Speter* Another approach is to have each site own a particular branch. This 47332785Speterone is the most tolerant of flaky networks; if checkins happen at each 47432785Spetersite independently there is no particular problem. The big question 47532785Speteris whether merges happen only manually, as with existing CVS branches, 47632785Speteror whether there is a feature whereby there are circumstances in which 47732785Spetermerges from one branch to the other happen automatically (for example, 47832785Speterthe case in which the branches have not diverged). This might be a 47932785Speterlegitimate question to ask even quite aside from multisite features. 48032785Speter 48132785Speter187. Might want to separate out usage error messages and help 48232785Spetermessages. The problem now is that if you specify an invalid option, 48332785Speterfor example, the error message is lost among all the help text. In 48432785Speterthe new regime, the error message would be followed by a one-line 48532785Spetermessage directing people to the appropriate help option ("cvs -H 48632785Speter<command>" or "cvs --help-commands" or whatever, according to the 48732785Spetersituation). I'm not sure whether this change would be controversial 48832785Speter(as defined in HACKING), so there might be a need for further 48932785Speterdiscussion or other actions other than just coding. 49032785Speter 49132785Speter188. Option parsing and .cvsrc has at least one notable limitation. 49232785SpeterIf you want to set a global option only for some CVS commands, there 49332785Speteris no way to do it (for example, if one wants to set -q only for 49432785Speter"rdiff"). I am told that the "popt" package from RPM 49532785Speter(http://www.rpm.org) could solve this and other problems (for example, 49632785Speterif the syntax of option stuff in .cvsrc is similar to RPM, that would 49732785Speterbe great from a user point of view). It would at least be worth a 49832785Speterlook (it also provides a cleaner API than getopt_long). 49932785Speter 50032785SpeterAnother issue which may or may not be related is the issue of 50132785Speteroverriding .cvsrc from the command line. The cleanest solution might 50232785Speterbe to have options in mutually exclusive sets (-l/-R being a current 50332785Speterexample, but --foo/--no-foo is a better way to name such options). Or 50432785Speterperhaps there is some better solution. 50532785Speter 50632785Speter189. Renaming files and directories is a frequently discussed topic. 50732785Speter 50832785SpeterSome of the problems with the status quo: 50932785Speter 51032785Spetera. "cvs annotate" cannot operate on both the old and new files in a 51132785Spetersingle run. You need to run it twice, once for the new name and once 51232785Speterfor the old name. 51332785Speter 51432785Speterb. "cvs diff" (or "cvs diff -N") shows a rename as a removal of the 51532785Speterold file and an addition of the new one. Some people would like to 51632785Spetersee the differences between the file contents (but then how would we 51732785Speterindicate the fact that the file has been renamed? Certainly the 51832785Speternotion that "patch(1)" has of renames is as a removal and addition). 51932785Speter 52032785Speterc. "cvs log" should be able to show the changes between two 52132785Spetertags/dates, even in the presence of adds/removes/renames (I'm not sure 52232785Speterwhat the status quo is on this; see also item #182). 52332785Speter 52432785Speterd. Renaming directories is way too hard. 52532785Speter 52632785SpeterImplementations: 52732785Speter 52832785SpeterIt is perhaps premature to try to design implementation details 52932785Speterwithout answering some of the above questions about desired behaviors 53032785Speterbut several general implementations get mentioned. 53132785Speter 53232785Speteri. No fundamental changes (for example, a "cvs rename" command which 53332785Speteroperated on directories could still implement the current recommended 53432785Speterpractice for renaming directories, which is to rename each of the 53532785Speterfiles contained therein via an add and a remove). One thing to note 53632785Speterthat the status quo gets right is proper merges, even with adds and 53732785Speterremovals (Well, mostly right at least. There are a *LOT* of different 53832785Spetercases; see the testsuite for some of them). 53932785Speter 54032785Speterii. Rename database. In this scheme the files in the repository 54132785Speterwould have some arbitrary name, and then a separate rename database 54232785Speterwould indicate the current correspondence between the filename in the 54332785Speterworking directory and the actual storage. As far as I know this has 54432785Speternever been designed in detail for CVS. 54532785Speter 54632785Speteriii. A modest change in which the RCS files would contain some 54732785Speterinformation such as "renamed from X" or "renamed to Y". That is, this 54832785Speterwould be generally similar to the log messages which are suggested 54932785Speterwhen one renames via an add and a removal, but would be 55032785Spetercomputer-parseable. I don't think anyone has tried to flesh out any 55132785Speterdetails here either. 55232785Speter 55332785SpeterIt is interesting to note that in solution ii. version numbers in the 55432785Speter"new file" start where the "old file" left off, while in solutions 55532785Speteri. and iii., version numbers restart from 1.1 each time a file is 55632785Speterrenamed. Except perhaps in the case where we rename a file from foo 55732785Speterto bar and then back to foo. I'll shut up now. 55832785Speter 55932785SpeterRegardless of the method we choose, we need to address how renames 56032785Speteraffect existing CVS behaviors. For example, what happens when you 56132785Speterrename a file on a branch but not the trunk and then try to merge the 56232785Spetertwo? What happens when you rename a file on one branch and delete it 56332785Speteron another and try to merge the two? 56432785Speter 56532785SpeterIdeally, we'd come up with a way to parameterize the problem and 56632785Spetersimply write up a lookup table to determine the correct behavior. 56732785Speter 56832785Speter190. The meaning of the -q and -Q global options is very ad hoc; 56932785Speterthere is no clear definition of which messages are suppressed by them 57032785Speterand which are not. Here is a classification of the current meanings 57132785Speterof -q; I don't know whether anyone has done a similar investigation of 57232785Speter-Q: 57332785Speter 57432785Speter a. The "warm fuzzies" printed upon entering each directory (for 57532785Speter example, "cvs update: Updating sdir"). The need for these messages 57632785Speter may be decreased now that most of CVS uses ->fullname instead of 57732785Speter ->file in messages (a project which is *still* not 100% complete, 57832785Speter alas). However, the issue of whether CVS can offer status as it 57932785Speter runs is an important one. Of course from the command line it is 58032785Speter hard to do this well and one ends up with options like -q. But 58132785Speter think about emacs, jCVS, or other environments which could flash you 58232785Speter the latest status line so you can see whether the system is working 58332785Speter or stuck. 58432785Speter 58532785Speter b. Other cases where the message just offers information (rather 58632785Speter than an error) and might be considered unnecessarily verbose. These 58732785Speter have a certain point to them, although it isn't really clear whether 58832785Speter it should be the same option as the warm fuzzies or whether it is 58932785Speter worth the conceptual hair: 59032785Speter 59132785Speter add.c: scheduling %s `%s' for addition (may be an issue) 59232785Speter modules.c: %s %s: Executing '%s' (I can see how that might be noise, 59332785Speter but...) 59432785Speter remove.c: scheduling `%s' for removal (analogous to the add.c one) 59532785Speter update.c: Checking out %s (hmm, that message is a bit on the noisy side...) 59632785Speter (but the similar message in annotate is not affected by -q). 59732785Speter 59832785Speter c. Suppressing various error messages. This is almost surely 59932785Speter bogus. 60032785Speter 60132785Speter commit.c: failed to remove tag `%s' from `%s' (Questionable. 60232785Speter Rationale might be that we already printed another message 60332785Speter elsewhere but why would it be necessary to avoid 60432785Speter the extra message in such an uncommon case?) 60532785Speter commit.c: failed to commit dead revision for `%s' (likewise) 60632785Speter remove.c: file `%s' still in working directory (see below about rm 60732785Speter -f analogy) 60832785Speter remove.c: nothing known about `%s' (looks dubious to me, especially in 60932785Speter the case where the user specified it explicitly). 61032785Speter remove.c: removed `%s' (seems like an obscure enough case that I fail 61132785Speter to see the appeal of being cryptically concise here). 61232785Speter remove.c: file `%s' already scheduled for removal (now it is starting 61332785Speter to look analogous to the infamous rm -f option). 61432785Speter rtag.c: cannot find tag `%s' in `%s' (more rm -f like behavior) 61532785Speter rtag.c: failed to remove tag `%s' from `%s' (ditto) 61632785Speter tag.c: failed to remove tag %s from %s (see above about whether RCS_* 61732785Speter has already printed an error message). 61832785Speter tag.c: couldn't tag added but un-commited file `%s' (more rm -f 61932785Speter like behavior) 62032785Speter tag.c: skipping removed but un-commited file `%s' (ditto) 62132785Speter tag.c: cannot find revision control file for `%s' (ditto, but at first 62232785Speter glance seems even worse, as this would seem to be a "can't happen" 62332785Speter condition) 62432785Speter 62532785Speter191. Storing RCS files, especially binary files, takes rather more 62632785Speterspace than it could, typically. 62732785Speter - The virtue of the status quo is that it is simple to implement. 62832785Speter Of course it is also simplest in terms of dealing with compatibility. 62932785Speter - Just storing the revisions as separate gzipped files is a common 63032785Speter technique. It also is pretty simple (no new algorithms, CVS 63132785Speter already has zlib around). Of course for some files (such as files 63232785Speter which are already compressed) the gzip step won't help, but 63332785Speter something which can at least sometimes avoid rewriting the entire 63432785Speter RCS file for each new revision would, I would think, be a big 63532785Speter speedup for large files. 63632785Speter - Josh MacDonald has written a tool called xdelta which produces 63732785Speter differences (that is, sufficient information to transform the old 63832785Speter to the new) which looks for common sequences of bytes, like RCS 63932785Speter currently does, but which is not based on lines. This seems to do 64032785Speter quite well for some kinds of files (e.g. FrameMaker documents, 64132785Speter text files), and not as well for others (anything which is already 64232785Speter compressed, executables). xdelta 1.10 also is faster than GNU diff. 64332785Speter - Karl Fogel has thought some about using a difference technique 64432785Speter analogous to fractal compression (see the comp.compression FAQ for 64532785Speter more on fractal compression, including at least one patent to 64632785Speter watch for; I don't know how analogous Karl's ideas are to the 64732785Speter techniques described there). 64832785Speter - Quite possibly want some documented interface by which a site can 64932785Speter plug in their choice of external difference programs (with the 65032785Speter ability to choose the program based on filename, magic numbers, 65132785Speter or some such). 65232785Speter 65332785Speter192. "cvs update" using an absolute pathname does not work if the 65432785Speterworking directory is not a CVS-controlled directory with the correct 65532785SpeterCVSROOT. For example, the following will fail: 65632785Speter 65732785Speter cd /tmp 65832785Speter cvs -d /repos co foo 65932785Speter cd / 66032785Speter cvs update /tmp/foo 66132785Speter 66232785SpeterIt is possible to read the CVSROOT from the administrative files in 66332785Speterthe directory specified by the absolute pathname argument to update. 66432785SpeterIn that case, the last command above would be equivalent to: 66532785Speter 66632785Speter cd /tmp/foo 66732785Speter cvs update . 66832785Speter 66932785SpeterThis can be problematic, however, if we ask CVS to update two 67032785Speterdirectories with different CVSROOTs. Currently, CVS has no way of 67132785Speterchanging CVSROOT mid-stream. Consider the following: 67232785Speter 67332785Speter cd /tmp 67432785Speter cvs -d /repos1 co foo 67532785Speter cvs -d /repos2 co bar 67632785Speter cd / 67732785Speter cvs update /tmp/foo /tmp/bar 67832785Speter 67932785SpeterTo make that example work, we need to think hard about: 68032785Speter 68132785Speter - where and when CVSROOT-related variables get set 68232785Speter - who caches said variables for later use 68332785Speter - how the remote protocol should be extended to handle sending a new 68432785Speter repository mid-stream 68532785Speter - how the client should maintain connections to a variety of servers 68632785Speter in a single invocation. 68732785Speter 68832785SpeterBecause those issues are hairy, I suspect that having a change in 68932785SpeterCVSROOT be an error would be a better move. 69032785Speter 69132785Speter193. The client relies on timestamps to figure out whether a file is 69232785Speter(maybe) modified. If something goes awry, then it ends up sending 69332785Speterentire files to the server to be checked, and this can be quite slow 69432785Speterespecially over a slow network. A couple of things that can happen: 69532785Speter(a) other programs, like make, use timestamps, so one ends up needing 69632785Speterto do "touch foo" and otherwise messing with timestamps, (b) changing 69732785Speterthe timezone offset (e.g. summer vs. winter or moving a machine) 69832785Spetershould work on unix, but there may be problems with non-unix. 69932785Speter 70032785SpeterPossible solutions: 70132785Speter 70232785Speter a. Store a checksum for each file in CVS/Entries or some such 70332785Speter place. What to do about hash collisions is interesting: using a 70432785Speter checksum, like MD5, large enough to "never" have collisions 70532785Speter probably works in practice (of course, if there is a collision then 70632785Speter all hell breaks loose because that code path was not tested, but 70732785Speter given the tiny, tiny probability of that I suppose this is only an 70832785Speter aesthetic issue). 70932785Speter 71032785Speter b. I'm not thinking of others, except storing the whole file in 71132785Speter CVS/Base, and I'm sure using twice the disk space would be 71232785Speter unpopular. 71332785Speter 71432785Speter194. CVS does not separate the "metadata" from the actual revision 71532785Speterhistory; it stores them both in the RCS files. Metadata means tags 71632785Speterand header information such as the number of the head revision. 71732785SpeterStoring the metadata separately could speed up "cvs tag" enormously, 71832785Speterwhich is a big problem for large repositories. It could also probably 71932785Spetermake CVS's locking much less in the way (see comment in do_recursion 72032785Speterabout "two-pass design"). 72132785Speter 72232785Speter195. Many people using CVS over a slow link are interested in whether 72332785Speterthe remote protocol could be any more efficient with network 72432785Speterbandwidth. This item is about one aspect of that--how the server 72532785Spetersends a new version of a file the client has a different version of, 72632785Speteror vice versa. 72732785Speter 72832785Spetera. Cases in which the status quo already sends a diff. For most text 72932785Speterfiles, this is probably already close to optimal. For binary files, 73054427Speterand anomalous (?) text files (e.g. those in which it would help to do 73154427Spetermoves, as well as adds and deletes), it might be worth looking into other 73232785Speterdifference algorithms (see item #191). 73332785Speter 73432785Speterb. Cases in which the status quo does not send a diff (e.g. "cvs 73532785Spetercommit"). 73632785Speter 73732785Speterb1. With some frequency, people suggest rsync or a similar algorithm 73832785Speter(see ftp://samba.anu.edu.au/pub/rsync/). This could speed things up, 73932785Speterand in some ways involves the most minimal changes to the default CVS 74032785Speterparadigm. There are some downsides though: (1) there is an extra 74154427Speternetwork turnaround, (2) the algorithm needs to transmit some data to 74254427Speterdiscover what difference type programs can discover locally (although 74354427Speterthis is only about 1% of the size of the files). 74432785Speter 74532785Speterb2. If one is willing to require that users use "cvs edit" before 74632785Speterediting a file on the client side (in some cases, a development 74732785Speterenvironment like emacs can make this fairly easy), then the Modified 74832785Speterrequest in the protocol could be extended to allow the client to just 74932785Spetersend differences instead of entire files. In the degenerate case 75032785Speter(e.g. "cvs diff" without arguments) the required network traffic is 75132785Speterreduced to zero, and the client need not even contact the server. 75254427Speter 75381404Speter197. Analyze the difference between CVS_UNLINK & unlink_file. As far as I 75481404Spetercan tell, unlink_file aborts in noexec mode and CVS_UNLINK does not. I'm not 75581404Spetersure it would be possible to remove even the use of temp files in noexec mode, 75681404Speterbut most unlinks should probably be using unlink_file and not CVS_UNLINK. 75781404Speter 75881404Speter198. Remove references to deprecated cvs_temp_name function. 75981404Speter 76081404Speter199. Add test for login & logout functionality, including support for 76181404Speterbackwards compatibility with old CVSROOTs. 76281404Speter 763102840Speter200. Make a 'cvs add' without write access a non-fatal error so that 764102840Speterthe user's Entries file is updated and future 'cvs diffs' will work 765102840Speterproperly. This should ease patch submission. 76681404Speter 76781404Speter201. cvs_temp_file should be creating temporary files in a privately owned 76881404Spetersubdirectory of of temp due to security issues on some systems. 76981404Speter 770107484Speter202. Enable rdiff to accept most diff options. Make rdiff output look 771107484Speterlike diff's. Make CVS diff garbage go to stderr and only standard diff 772107484Speteroutput go to stdout. 773102840Speter 774102840Speter203. Add val-tags additions to the tagging code. Don't remove the 775102840Speterupdate additions since val-tags could still be used as a cache when the 776102840Speterrepository was imported from elsewhere (the tags weren't applied with a 777102840Speterversion which wrote val-tags). 778102840Speter 779102840Speter204. Add test case for compression. A buf_shutdown error using compression 780102840Speterwasn't caught by the test suite. 781102840Speter 782102840Speter205. There are lots of cases where trailing slashes on directory names 783102840Speterand other non-canonical paths confuse CVS. Most of the cases that do 784102840Speterwork are handled on an ad-hoc basis. We need to come up with a coherent 785102840Speterstrategy to address path canonicalization and apply it consistently. 786102840Speter 787107484Speter208. Merge enhancements to the diff package back into the original GNU source. 788107484Speter 789107484Speter209. Go through this file and try to: 790107484Speter 791107484Speter a. Verify that items are still valid. 792107484Speter 793107484Speter b. Create test cases for valid items when they don't exist. 794107484Speter 795107484Speter c. Remove fixed and no longer applicable items. 796107484Speter 797107484Speter210. Explain to sanity.sh how to deal with paths with spaces and other odd 798107484Spetercharacters in them. 799107484Speter 800107484Speter211. Make sanity.sh run under the Win32 bash (cygwin) and maybe other Windex 801107484Speterenvironments (e.g. DGSS or whatever the MSVC portability environemnt is called). 802107484Speter 803107484Speter212. Autotestify (see autoconf source) sanity.sh. 804107484Speter 805107484Speter213. Examine desirability of updating the regex library (regex.{c,h}) to the 806107484Spetermore recent versions that come with glibc and emacs. It might be worth waiting 807107484Speterfor the emacs folks to get their act together and merge their changes into the 808107484Speterglibc version. 809107484Speter 810107484Speter214. Make options.h options configure script options instead. 811107484Speter 812107484Speter215. Add reditors and rwatchers commands. 813107484Speter 814107484Speter - Is an r* command abstraction layer possible here for the commands 815107484Speter where this makes sense? Would it be simpler? It seems to me the 816107484Speter major operational differences lie in the file list construction. 817107484Speter 818107484Speter218. Fix "checkout -d ." in client/server mode. 819107484Speter 820107484Speter221. Handle spaces in file/directory names. (Most, if not all, of the 821107484Speterinternal infrastructure already handles them correctly, but most of the 822107484Speteradministrative file interfaces do not.) 823107484Speter 824107484Speter223. Internationalization support. This probably means using some kind 825107484Speterof universal character set (ISO 10646?) internally and converting on 826107484Speterinput and output, which opens the locale can of worms. 827107484Speter 828107484Speter224. Better timezone handling. Many people would like to see times 829107484Speteroutput in local time rather than UTC, but that's tricky since the 830107484Speterconversion from internal form is currently done by the server who has no 831107484Speteridea what the user's timezone even is, let alone the rules for 832107484Speterconverting to it. 833107484Speter 834107484Speter - On the contrary, I think the MT server response should be easily adaptable 835107484Speterfor this purpose. It is defined in cvsclient.texi as processed by the client 836107484Speterif it knows how and printed to stdout otherwise. A "time" tag or the like 837107484Spetercould be the usual CVS server UTC time string. An old client could just print 838107484Speterthe time in UTC and a new client would know that it could convert the time to a 839107484Speterlocal time string according to the localization settings before printing it. 840107484Speter 841107484Speter225. Add support for --allow-root to server command. 842107484Speter 843107484Speter227. 'cvs release' should use the CVS/Root in the directory being released 844107484Speterwhen such is specified rather than $CVSROOT. In my work directory with no CVS 845107484Speterdir, a release of subdirectories causes the released projects to be tested 846107484Speteragainst my $CVSROOT environment variable, which often isn't correct but which 847107484Spetercan complete without generating error messages if the project also exists in 848107484Speterthe other CVSROOT. This happens a lot with my copies of the ccvs project. 849128266Speter 850128266Speter228. Consider adding -d to commit ala ci. 851128266Speter 852128266Speter229. Improve the locking code to use a random delay with exponential 853128266Speterbackoff ala Ethernet and separate the notification interval from the 854128266Speterwait interval. 855128266Speter 856128266Speter230. Support for options like compression as part of the CVSROOT might be 857128266Speternice. This should be fairly easy to implement now using the method options. 858175261Sobrien 859175261Sobrien234. Noop commands should be logged in the history file. Information can 860175261Sobrienstill be obtained with noop commands, for instance via `cvs -n up -p', and 861175261Sobrienparanoid admins might appreciate this. Similarly, perhaps diff operations 862175261Sobrienshould be logged. 863