1The "TODO" file! -*-Indented-Text-*- 2 338. Think hard about using RCS state information to allow one to checkin 4 a new vendor release without having it be accessed until it has been 5 integrated into the local changes. 6 739. Think about a version of "cvs update -j" which remembers what from 8 that other branch is already merged. This has pitfalls--it could 9 easily lead to invisible state which could confuse users very 10 rapidly--but having to create a tag or some such mechanism to keep 11 track of what has been merged is a pain. Take a look at PRCS 1.2. 12 PRCS 1.0 was particularly bad the way it handled the "invisible 13 state", but 1.2 is significantly better. 14 1552. SCCS has a feature that I would *love* to see in CVS, as it is very 16 useful. One may make a private copy of SCCS suid to a particular user, 17 so other users in the authentication list may check files in and out of 18 a project directory without mucking about with groups. Is there any 19 plan to provide a similar functionality to CVS? Our site (and, I'd 20 imagine, many other sites with large user bases) has decided against 21 having the user-groups feature of unix available to the users, due to 22 perceived administrative, technical and performance headaches. A tool 23 such as CVS with features that provide group-like functionality would 24 be a huge help. 25 2662. Consider using revision controlled files and directories to handle the 27 new module format -- consider a cvs command front-end to 28 add/delete/modify module contents, maybe. 29 3063. The "import" and vendor support commands (co -j) need to be documented 31 better. 32 3366. Length of the CVS temporary files must be limited to 14 characters for 34 System-V stupid support. As well as the length on the CVS.adm files. 35 3672. Consider re-design of the module -t options to use the file system more 37 intuitively. 38 3973. Consider an option (in .cvsrc?) to automatically add files that are new 40 and specified to commit. 41 4279. Might be nice to have some sort of interface to Sun's Translucent 43 (?) File System and tagged revisions. 44 4582. Maybe the import stuff should allow an arbitrary revision to be 46 specified. 47 4884. Improve the documentation about administration of the repository and 49 how to add/remove files and the use of symbolic links. 50 5185. Make symbolic links a valid thing to put under version control. 52 Perhaps use one of the tag fields in the RCS file? Note that we 53 can only support symlinks that are relative and within the scope of 54 the sources being controlled. 55 5693. Need to think hard about release and development environments. Think 57 about execsets as well. 58 5998. If diff3 bombs out (too many differences) cvs then thinks that the file 60 has been updated and is OK to be commited even though the file 61 has not yet been merged. 62 63100. Checked out files should have revision control support. Maybe. 64 65102. Perhaps directory modes should be propagated on all import check-ins. 66 Not necessarily uid/gid changes. 67 68103. setuid/setgid on files is suspect. 69 70104. cvs should recover nicely on unreadable files/directories. 71 72105. cvs should have administrative tools to allow for changing permissions 73 and modes and what not. In particular, this would make cvs a 74 more attractive alternative to rdist. 75 76107. It should be possible to specify a list of symbolic revisions to 77 checkout such that the list is processed in reverse order looking for 78 matches within the RCS file for the symbolic revision. If there is 79 not a match, the next symbolic rev on the list is checked, and so on, 80 until all symbolic revs are exhausted. This would allow one to, say, 81 checkout "4.0" + "4.0.3" + "4.0.3Patch1" + "4.0.3Patch2" to get the 82 most recent 4.x stuff. This is usually handled by just specifying the 83 right release_tag, but most people forget to do this. 84 85108. If someone creates a whole new directory (i.e. adds it to the cvs 86 repository) and you happen to have a directory in your source farm by 87 the same name, when you do your cvs update -d it SILENTLY does 88 *nothing* to that directory. At least, I think it was silent; 89 certainly, it did *not* abort my cvs update, as it would have if the 90 same thing had happened with a file instead of a directory. 91 92109. I had gotten pieces of the sys directory in the past but not a 93 complete tree. I just did something like: 94 95 cvs get * 96 97 Where sys was in * and got the message 98 99 cvs get: Executing 'sys/tools/make_links sys' 100 sh: sys/tools/make_links: not found 101 102 I suspect this is because I didn't have the file in question, 103 but I do not understand how I could fool it into getting an 104 error. I think a later cvs get sys seemed to work so perhaps 105 something is amiss in handling multiple arguments to cvs get? 106 107119. When importing a directory tree that is under SCCS/RCS control, 108 consider an option to have import checkout the SCCS/RCS files if 109 necessary. (This is if someone wants to import something which 110 is in RCS or SCCS without preserving the history, but makes sure 111 they do get the latest versions. It isn't clear to me how useful 112 that is -kingdon, June 1996). 113 114122. If Name_Repository fails, it currently causes CVS to die completely. It 115 should instead return NULL and have the caller do something reasonable 116 (??? -what is reasonable? I'm not sure there is a real problem here. 117 -kingdon, June 1996). 118 119123. Add a flag to import to not build vendor branches for local code. 120 (See `importb' tests in src/sanity.sh for more details). 121 122124. Anyway, I thought you might want to add something like the following 123 to the cvs man pages: 124 125 BUGS 126 The sum of the sizes of a module key and its contents are 127 limited. See ndbm(3). 128 129126. Do an analysis to see if CVS is forgetting to close file descriptors. 130 Especially when committing many files (more than the open file limit 131 for the particular UNIX). 132 133127. Look at *info files; they should all be quiet if the files are not 134 there. Should be able to point at a RCS directory and go. 135 136130. cvs diff with no -r arguments does not need to look up the current RCS 137 version number since it only cares about what's in the Entries file. 138 This should make it much faster. 139 140 It should ParseEntries itself and access the entries list much like 141 Version_TS does (sticky tags and sticky options may need to be 142 supported here as well). Then it should only diff the things that 143 have the wrong time stamp (the ones that look modified). 144 145134. Make a statement about using hard NFS mounts to your source 146 repository. Look into checking NULL fgets() returns with ferror() to 147 see if an error had occurred. (we should be checking for errors, quite 148 aside from NFS issues -kingdon, June 1996). 149 150137. Some sites might want CVS to fsync() the RCS ,v file to protect 151 against nasty hardware errors. There is a slight performance hit with 152 doing so, though, so it should be configurable in the .cvsrc file. 153 Also, along with this, we should look at the places where CVS itself 154 could be a little more synchronous so as not to lose data. 155 [[ I've done some of this, but it could use much more ]] 156 157138. Some people have suggested that CVS use a VPATH-like environment 158 variable to limit the amount of sources that need to be duplicated for 159 sites with giant source trees and no disk space. 160 161141. Import should accept modules as its directory argument. If we're 162 going to implement this, we should think hard about how modules 163 might be expanded and how to handle those cases. 164 165143. Update the documentation to show that the source repository is 166 something far away from the files that you work on. (People who 167 come from an RCS background are used to their `repository' being 168 _very_ close to their working directory.) 169 170144. Have cvs checkout look for the environment variable CVSPREFIX 171 (or CVSMODPREFIX or some such). If it's set, then when looking 172 up an alias in the modules database, first look it up with the 173 value of CVSPREFIX attached, and then look for the alias itself. 174 This would be useful when you have several projects in a single 175 repository. You could have aliases abc_src and xyz_src and 176 tell people working on project abc to put "setenv CVSPREFIX abc_" 177 in their .cshrc file (or equivalent for other shells). 178 Then they could do "cvs co src" to get a copy of their src 179 directory, not xyz's. (This should create a directory called 180 src, not abc_src.) 181 182145. After you create revision 1.1.1.1 in the previous scenario, if 183 you do "cvs update -r1 filename" you get revision 1.1, not 184 1.1.1.1. It would be nice to get the later revision. Again, 185 this restriction comes from RCS and is probably hard to 186 change in CVS. Sigh. 187 188 |"cvs update -r1 filename" does not tell RCS to follow any branches. CVS 189 |tries to be consistent with RCS in this fashion, so I would not change 190 |this. Within CVS we do have the flexibility of extending things, like 191 |making a revision of the form "-r1HEAD" find the most recent revision 192 |(branch or not) with a "1." prefix in the RCS file. This would get what 193 |you want maybe. 194 195 This would be very useful. Though I would prefer an option 196 such as "-v1" rather than "-r1HEAD". This option might be 197 used quite often. 198 199146. The merging of files should be controlled via a hook so that programs 200 other than "rcsmerge" can be used, like Sun's filemerge or emacs's 201 emerge.el. (but be careful in making this work client/server--it means 202 doing the interactive merging at the end after the server is done). 203 (probably best is to have CVS do the non-interactive part and 204 tell the user about where the files are (.#foo.c.working and 205 .#foo.c.1.5 or whatever), so they can do the interactive part at 206 that point -kingdon, June 1996). 207 208149. Maybe there should be an option to cvs admin that allows a user to 209 change the Repository/Root file with some degree of error checking? 210 Something like "cvs admin reposmv /old/path /new/pretty/path". Before 211 it does the replace it check to see that the files 212 /new/pretty/path/<dir>/<files> exist. 213 214 The obvious cases are where one moves the repository to another 215 machine or directory. But there are other cases, like where the 216 user might want to change from :pserver: to :ext:, use a different 217 server (if there are two server machines which share the 218 repository using a networked file system), etc. 219 220 The status quo is a bit of a mess (as of, say, CVS 1.9). It is 221 that the -d global option has two moderately different uses. One 222 is to use a totally different repository (in which case we'd 223 probably want to give an error if it disagreed with CVS/Root, as 224 CVS 1.8 and earlier did). The other is the "reposmv" 225 functionality above (in which the two repositories really are the 226 same, and we want to update the CVS/Root files). In CVS 1.9 and 227 1.10, -d rewrites the CVS/Root file (but not in subdirectories). 228 This behavior was not particularly popular and has been since 229 reverted. 230 231 This whole area is a rather bad pile of individual decisions which 232 accumulated over time, some of them probably bad decisions with 233 hindsight. But we didn't get into this mess overnight, and we're 234 not going to get out of it overnight (that is, we need to come up 235 with a replacement behavior, document what parts of the status 236 quo are deprecated, probably circulate some unofficial patches, &c). 237 238 (this item originally added 2 Feb 1992 but revised since). 239 240150. I have a customer request for a way to specify log message per 241 file, non-interactively before the commit, such that a single, fully 242 recursive commit prompts for one commit message, and concatenates the 243 per file messages for each file. In short, one commit, one editor 244 session, log messages allowed to vary across files within the commit. 245 Also, the per file messages should be allowed to be written when the 246 files are changed, which may predate the commit considerably. 247 248 A new command seems appropriate for this. The state can be saved in the 249 CVS directory. I.e., 250 251 % cvs message foo.c 252 Enter log message for foo.c 253 >> fixed an uninitialized variable 254 >> ^D 255 256 The text is saved as CVS/foo.c,m (or some such name) and commit 257 is modified to append (prepend?) the text (if found) to the log 258 message specified at commit time. Easy enough. (having cvs 259 commit be non-interactive takes care of various issues like 260 whether to connect to the server before or after prompting for a 261 message (see comment in commit.c at call to start_server). Also 262 would clean up the kludge for what to do with the message from 263 do_editor if the up-to-date check fails (see commit.c client code). 264 265 I'm not sure about the part above about having commit prompt 266 for an overall message--part of the point is having commit 267 non-interactive and somehow combining messages seems like (excess?) 268 hair. 269 270 Would be nice to do this so it allows users more flexibility in 271 specifying messages per-directory ("cvs message -l") or per-tree 272 ("cvs message") or per-file ("cvs message foo.c"), and fixes the 273 incompatibility between client/server (per-tree) and 274 non-client/server (per-directory). 275 276 A few interesting issues with this: (1) if you do a cvs update or 277 some other operation which changes the working directory, do you 278 need to run "cvs message" again (it would, of course, bring up 279 the old message which you could accept)? Probably yes, after all 280 merging in some conflicts might change the situation. (2) How do 281 you change the stored messages if you change your mind before the 282 commit (probably run "cvs message" again, as hinted in (1))? 283 284151. Also, is there a flag I am missing that allows replacing Ulrtx_Build 285 by Ultrix_build? I.E. I would like a tag replacement to be a one step 286 operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build" 287 followed by "cvs rtag -d Ulrtx_Build" 288 289152. The "cvs -n" option does not work as one would expect for all the 290 commands. In particular, for "commit" and "import", where one would 291 also like to see what it would do, without actually doing anything. 292 293153. There should be some command (maybe I just haven't figured out 294 which one...) to import a source directory which is already 295 RCS-administered without losing all prior RCS gathered data. 296 Thus, it would have to examine the RCS files and choose a 297 starting version and branch higher than previous ones used. 298 (Check out rcs-to-cvs and see if it addresses this issue.) 299 300154. When committing the modules file, a pre-commit check should be done to 301 verify the validity of the new modules file before allowing it to be 302 committed. 303 304155. The options for "cvs history" are mutually exclusive, even though 305 useful queries can be done if they are not, as in specifying both 306 a module and a tag. A workaround is to specify the module, then 307 run the output through grep to only display lines that begin with 308 T, which are tag lines. (Better perhaps if we redesign the whole 309 "history" business -- check out doc/cvs.texinfo for the entire 310 rant.) 311 312156. Also, how hard would it be to allow continuation lines in the 313 {commit,rcs,log}info files? It would probably be useful with all of 314 the various flags that are now available, or if somebody has a lot of 315 files to put into a module. 316 317158. If I do a recursive commit and find that the same RCS file is checked 318 out (and modified!) in two different places within my checked-out 319 files (but within the realm of a single "commit"), CVS will commit the 320 first change, then overwrite that change with the second change. We 321 should catch this (typically unusual) case and issue an appropriate 322 diagnostic and die. 323 324160. The checks that the commit command does should be extended to make 325 sure that the revision that we will lock is not already locked by 326 someone else. Maybe it should also lock the new revision if the old 327 revision was already locked by the user as well, thus moving the lock 328 forward after the commit. 329 330163. The rtag/tag commands should have an option that removes the specified 331 tag from any file that is in the attic. This allows one to re-use a 332 tag (like "Mon", "Tue", ...) all the time and still have it tag the 333 real main-line code. 334 335165. The "import" command will create RCS files automatically, but will 336 screw-up when trying to create long file names on short file name 337 file systems. Perhaps import should be a bit more cautious. 338 339166. There really needs to be a "Getting Started" document which describes 340 some of the new CVS philosophies. Folks coming straight from SCCS or 341 RCS might be confused by "cvs import". Also need to explain: 342 - How one might setup their $CVSROOT 343 - What all the tags mean in an "import" command 344 - Tags are important; revision numbers are not 345 346170. Is there an "info" file that can be invoked when a file is checked out, or 347 updated ? What I want to do is to advise users, particularly novices, of 348 the state of their working source whenever they check something out, as 349 a sanity check. 350 351 For example, I've written a perl script which tells you what branch you're 352 on, if any. Hopefully this will help guard against mistaken checkins to 353 the trunk, or to the wrong branch. I suppose I can do this in 354 "commitinfo", but it'd be nice to advise people before they edit their 355 files. 356 357 It would also be nice if there was some sort of "verboseness" switch to 358 the checkout and update commands that could turn this invocation of the 359 script off, for mature users. 360 361173. Need generic date-on-branch handling. Currently, many commands 362 allow both -r and -D, but that's problematic for commands like diff 363 that interpret that as two revisions rather than a single revision. 364 Checkout and update -j takes tag:date which is probably a better 365 solution overall. 366 367174. I would like to see "cvs release" modified so that it only removes files 368 which are known to CVS - all the files in the repository, plus those which 369 are listed in .cvsignore. This way, if you do leave something valuable in 370 a source tree you can "cvs release -d" the tree and your non-CVS goodies 371 are still there. If a user is going to leave non-CVS files in their source 372 trees, they really should have to clean them up by hand. 373 374175. And, in the feature request department, I'd dearly love a command-line 375 interface to adding a new module to the CVSROOT/modules file. 376 377176. If you use the -i flag in the modules file, you can control access 378 to source code; this is a Good Thing under certain circumstances. I 379 just had a nasty thought, and on experiment discovered that the 380 filter specified by -i is _not_ run before a cvs admin command; as 381 this allows a user to go behind cvs's back and delete information 382 (cvs admin -o1.4 file) this seems like a serious problem. 383 384177. We've got some external vendor source that sits under a source code 385 hierarchy, and when we do a cvs update, it gets wiped out because 386 its tag is different from the "main" distribution. I've tried to 387 use "-I" to ignore the directory, as well as .cvsignore, but this 388 doesn't work. 389 390179. "cvs admin" does not log its actions with loginfo, nor does it check 391 whether the action is allowed with commitinfo. It should. 392 393180. "cvs edit" should show you who is already editing the files, 394 probably (that is, do "cvs editors" before executing, or some 395 similar result). (But watch out for what happens if the network 396 is down!). 397 398182. There should be a way to show log entries corresponding to 399changes from tag "foo" to tag "bar". "cvs log -rfoo:bar" doesn't cut 400it, because it erroneously shows the changes associated with the 401change from the revision before foo to foo. I'm not sure that is ever 402a useful or logical behavior ("cvs diff -r foo -r bar" gets this 403right), but is compatibility an issue? See 404http://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch. 405 406183. "cvs status" should report on Entries.Static flag and CVS/Tag (how? 407maybe a "cvs status -d" to give directory status?). There should also 408be more documentation of how these get set and how/when to re-set them. 409 410184. Would be nice to implement the FreeBSD MD5-based password hash 411algorithm in pserver. For more info see "6.1. DES, MD5, and Crypt" in 412the FreeBSD Handbook, and src/lib/libcrypt/crypt.c in the FreeBSD 413sources. Certainly in the context of non-unix servers this algorithm 414makes more sense than the traditional unix crypt() algorithm, which 415suffers from export control problems. 416 417185. A frequent complaint is that keyword expansion causes conflicts 418when merging from one branch to another. The first step is 419documenting CVS's existing features in this area--what happens with 420various -k options in various places? The second step is thinking 421about whether there should be some new feature and if so how it should 422be designed. For example, here is one thought: 423 424 rcs' co command needs a new -k option. The new option should expand 425 $Log entries without expanding $Revision entries. This would 426 allow cvs to use rcsmerge in such a way that joining branches into 427 main lines would neither generate extra collisions on revisions nor 428 drop log lines. 429 430The details of this are out of date (CVS no longer invokes "co", and 431any changes in this area would be done by bypassing RCS rather than 432modifying it), but even as to the general idea, I don't have a clear 433idea about whether it would be good (see what I mean about the need 434for better documentation? I work on CVS full-time, and even I don't 435understand the state of the art on this subject). 436 437186. There is a frequent discussion of multisite features. 438 439* There may be some overlap with the client/server CVS, which is good 440especially when there is a single developer at each location. But by 441"multisite" I mean something in which each site is more autonomous, to 442one extent or another. 443 444* Vendor branches are the closest thing that CVS currently has for 445multisite features. They have fixable drawbacks (such as poor 446handling of added and removed files), and more fundamental drawbacks 447(when you import a vendor branch, you are importing a set of files, 448not importing any knowledge of their version history outside the 449current repository). 450 451* One approach would be to require checkins (or other modifications to 452the repository) to succeed at a write quorum of sites (51%) before 453they are allowed to complete. To work well, the network should be 454reliable enough that one can typically get to that many sites. When a 455server which has been out of touch reconnects, it would want to update 456its data before doing anything else. Any of the servers can service 457all requests locally, except perhaps for a check that they are 458up-to-date. The way this differs from a run-of-the-mill distributed 459database is that if one only allows reversible operations via this 460mechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site 461can back up the others, such that failures at one site, including 462something like deleting all the sources, can be recovered from. Thus 463the sites need not trust each other as much as for many shared 464databases, and the system may be resilient to many types of 465organizational failures. Sometimes I call this design the 466"CVScluster" design. 467 468* Another approach is a master/slave one. Checkins happen at the 469master site, and slave sites need to check whether their local 470repository is up to date before relying on its information. 471 472* Another approach is to have each site own a particular branch. This 473one is the most tolerant of flaky networks; if checkins happen at each 474site independently there is no particular problem. The big question 475is whether merges happen only manually, as with existing CVS branches, 476or whether there is a feature whereby there are circumstances in which 477merges from one branch to the other happen automatically (for example, 478the case in which the branches have not diverged). This might be a 479legitimate question to ask even quite aside from multisite features. 480 481187. Might want to separate out usage error messages and help 482messages. The problem now is that if you specify an invalid option, 483for example, the error message is lost among all the help text. In 484the new regime, the error message would be followed by a one-line 485message directing people to the appropriate help option ("cvs -H 486<command>" or "cvs --help-commands" or whatever, according to the 487situation). I'm not sure whether this change would be controversial 488(as defined in HACKING), so there might be a need for further 489discussion or other actions other than just coding. 490 491188. Option parsing and .cvsrc has at least one notable limitation. 492If you want to set a global option only for some CVS commands, there 493is no way to do it (for example, if one wants to set -q only for 494"rdiff"). I am told that the "popt" package from RPM 495(http://www.rpm.org) could solve this and other problems (for example, 496if the syntax of option stuff in .cvsrc is similar to RPM, that would 497be great from a user point of view). It would at least be worth a 498look (it also provides a cleaner API than getopt_long). 499 500Another issue which may or may not be related is the issue of 501overriding .cvsrc from the command line. The cleanest solution might 502be to have options in mutually exclusive sets (-l/-R being a current 503example, but --foo/--no-foo is a better way to name such options). Or 504perhaps there is some better solution. 505 506189. Renaming files and directories is a frequently discussed topic. 507 508Some of the problems with the status quo: 509 510a. "cvs annotate" cannot operate on both the old and new files in a 511single run. You need to run it twice, once for the new name and once 512for the old name. 513 514b. "cvs diff" (or "cvs diff -N") shows a rename as a removal of the 515old file and an addition of the new one. Some people would like to 516see the differences between the file contents (but then how would we 517indicate the fact that the file has been renamed? Certainly the 518notion that "patch(1)" has of renames is as a removal and addition). 519 520c. "cvs log" should be able to show the changes between two 521tags/dates, even in the presence of adds/removes/renames (I'm not sure 522what the status quo is on this; see also item #182). 523 524d. Renaming directories is way too hard. 525 526Implementations: 527 528It is perhaps premature to try to design implementation details 529without answering some of the above questions about desired behaviors 530but several general implementations get mentioned. 531 532i. No fundamental changes (for example, a "cvs rename" command which 533operated on directories could still implement the current recommended 534practice for renaming directories, which is to rename each of the 535files contained therein via an add and a remove). One thing to note 536that the status quo gets right is proper merges, even with adds and 537removals (Well, mostly right at least. There are a *LOT* of different 538cases; see the testsuite for some of them). 539 540ii. Rename database. In this scheme the files in the repository 541would have some arbitrary name, and then a separate rename database 542would indicate the current correspondence between the filename in the 543working directory and the actual storage. As far as I know this has 544never been designed in detail for CVS. 545 546iii. A modest change in which the RCS files would contain some 547information such as "renamed from X" or "renamed to Y". That is, this 548would be generally similar to the log messages which are suggested 549when one renames via an add and a removal, but would be 550computer-parseable. I don't think anyone has tried to flesh out any 551details here either. 552 553It is interesting to note that in solution ii. version numbers in the 554"new file" start where the "old file" left off, while in solutions 555i. and iii., version numbers restart from 1.1 each time a file is 556renamed. Except perhaps in the case where we rename a file from foo 557to bar and then back to foo. I'll shut up now. 558 559Regardless of the method we choose, we need to address how renames 560affect existing CVS behaviors. For example, what happens when you 561rename a file on a branch but not the trunk and then try to merge the 562two? What happens when you rename a file on one branch and delete it 563on another and try to merge the two? 564 565Ideally, we'd come up with a way to parameterize the problem and 566simply write up a lookup table to determine the correct behavior. 567 568190. The meaning of the -q and -Q global options is very ad hoc; 569there is no clear definition of which messages are suppressed by them 570and which are not. Here is a classification of the current meanings 571of -q; I don't know whether anyone has done a similar investigation of 572-Q: 573 574 a. The "warm fuzzies" printed upon entering each directory (for 575 example, "cvs update: Updating sdir"). The need for these messages 576 may be decreased now that most of CVS uses ->fullname instead of 577 ->file in messages (a project which is *still* not 100% complete, 578 alas). However, the issue of whether CVS can offer status as it 579 runs is an important one. Of course from the command line it is 580 hard to do this well and one ends up with options like -q. But 581 think about emacs, jCVS, or other environments which could flash you 582 the latest status line so you can see whether the system is working 583 or stuck. 584 585 b. Other cases where the message just offers information (rather 586 than an error) and might be considered unnecessarily verbose. These 587 have a certain point to them, although it isn't really clear whether 588 it should be the same option as the warm fuzzies or whether it is 589 worth the conceptual hair: 590 591 add.c: scheduling %s `%s' for addition (may be an issue) 592 modules.c: %s %s: Executing '%s' (I can see how that might be noise, 593 but...) 594 remove.c: scheduling `%s' for removal (analogous to the add.c one) 595 update.c: Checking out %s (hmm, that message is a bit on the noisy side...) 596 (but the similar message in annotate is not affected by -q). 597 598 c. Suppressing various error messages. This is almost surely 599 bogus. 600 601 commit.c: failed to remove tag `%s' from `%s' (Questionable. 602 Rationale might be that we already printed another message 603 elsewhere but why would it be necessary to avoid 604 the extra message in such an uncommon case?) 605 commit.c: failed to commit dead revision for `%s' (likewise) 606 remove.c: file `%s' still in working directory (see below about rm 607 -f analogy) 608 remove.c: nothing known about `%s' (looks dubious to me, especially in 609 the case where the user specified it explicitly). 610 remove.c: removed `%s' (seems like an obscure enough case that I fail 611 to see the appeal of being cryptically concise here). 612 remove.c: file `%s' already scheduled for removal (now it is starting 613 to look analogous to the infamous rm -f option). 614 rtag.c: cannot find tag `%s' in `%s' (more rm -f like behavior) 615 rtag.c: failed to remove tag `%s' from `%s' (ditto) 616 tag.c: failed to remove tag %s from %s (see above about whether RCS_* 617 has already printed an error message). 618 tag.c: couldn't tag added but un-commited file `%s' (more rm -f 619 like behavior) 620 tag.c: skipping removed but un-commited file `%s' (ditto) 621 tag.c: cannot find revision control file for `%s' (ditto, but at first 622 glance seems even worse, as this would seem to be a "can't happen" 623 condition) 624 625191. Storing RCS files, especially binary files, takes rather more 626space than it could, typically. 627 - The virtue of the status quo is that it is simple to implement. 628 Of course it is also simplest in terms of dealing with compatibility. 629 - Just storing the revisions as separate gzipped files is a common 630 technique. It also is pretty simple (no new algorithms, CVS 631 already has zlib around). Of course for some files (such as files 632 which are already compressed) the gzip step won't help, but 633 something which can at least sometimes avoid rewriting the entire 634 RCS file for each new revision would, I would think, be a big 635 speedup for large files. 636 - Josh MacDonald has written a tool called xdelta which produces 637 differences (that is, sufficient information to transform the old 638 to the new) which looks for common sequences of bytes, like RCS 639 currently does, but which is not based on lines. This seems to do 640 quite well for some kinds of files (e.g. FrameMaker documents, 641 text files), and not as well for others (anything which is already 642 compressed, executables). xdelta 1.10 also is faster than GNU diff. 643 - Karl Fogel has thought some about using a difference technique 644 analogous to fractal compression (see the comp.compression FAQ for 645 more on fractal compression, including at least one patent to 646 watch for; I don't know how analogous Karl's ideas are to the 647 techniques described there). 648 - Quite possibly want some documented interface by which a site can 649 plug in their choice of external difference programs (with the 650 ability to choose the program based on filename, magic numbers, 651 or some such). 652 653192. "cvs update" using an absolute pathname does not work if the 654working directory is not a CVS-controlled directory with the correct 655CVSROOT. For example, the following will fail: 656 657 cd /tmp 658 cvs -d /repos co foo 659 cd / 660 cvs update /tmp/foo 661 662It is possible to read the CVSROOT from the administrative files in 663the directory specified by the absolute pathname argument to update. 664In that case, the last command above would be equivalent to: 665 666 cd /tmp/foo 667 cvs update . 668 669This can be problematic, however, if we ask CVS to update two 670directories with different CVSROOTs. Currently, CVS has no way of 671changing CVSROOT mid-stream. Consider the following: 672 673 cd /tmp 674 cvs -d /repos1 co foo 675 cvs -d /repos2 co bar 676 cd / 677 cvs update /tmp/foo /tmp/bar 678 679To make that example work, we need to think hard about: 680 681 - where and when CVSROOT-related variables get set 682 - who caches said variables for later use 683 - how the remote protocol should be extended to handle sending a new 684 repository mid-stream 685 - how the client should maintain connections to a variety of servers 686 in a single invocation. 687 688Because those issues are hairy, I suspect that having a change in 689CVSROOT be an error would be a better move. 690 691193. The client relies on timestamps to figure out whether a file is 692(maybe) modified. If something goes awry, then it ends up sending 693entire files to the server to be checked, and this can be quite slow 694especially over a slow network. A couple of things that can happen: 695(a) other programs, like make, use timestamps, so one ends up needing 696to do "touch foo" and otherwise messing with timestamps, (b) changing 697the timezone offset (e.g. summer vs. winter or moving a machine) 698should work on unix, but there may be problems with non-unix. 699 700Possible solutions: 701 702 a. Store a checksum for each file in CVS/Entries or some such 703 place. What to do about hash collisions is interesting: using a 704 checksum, like MD5, large enough to "never" have collisions 705 probably works in practice (of course, if there is a collision then 706 all hell breaks loose because that code path was not tested, but 707 given the tiny, tiny probability of that I suppose this is only an 708 aesthetic issue). 709 710 b. I'm not thinking of others, except storing the whole file in 711 CVS/Base, and I'm sure using twice the disk space would be 712 unpopular. 713 714194. CVS does not separate the "metadata" from the actual revision 715history; it stores them both in the RCS files. Metadata means tags 716and header information such as the number of the head revision. 717Storing the metadata separately could speed up "cvs tag" enormously, 718which is a big problem for large repositories. It could also probably 719make CVS's locking much less in the way (see comment in do_recursion 720about "two-pass design"). 721 722195. Many people using CVS over a slow link are interested in whether 723the remote protocol could be any more efficient with network 724bandwidth. This item is about one aspect of that--how the server 725sends a new version of a file the client has a different version of, 726or vice versa. 727 728a. Cases in which the status quo already sends a diff. For most text 729files, this is probably already close to optimal. For binary files, 730and anomalous (?) text files (e.g. those in which it would help to do 731moves, as well as adds and deletes), it might be worth looking into other 732difference algorithms (see item #191). 733 734b. Cases in which the status quo does not send a diff (e.g. "cvs 735commit"). 736 737b1. With some frequency, people suggest rsync or a similar algorithm 738(see ftp://samba.anu.edu.au/pub/rsync/). This could speed things up, 739and in some ways involves the most minimal changes to the default CVS 740paradigm. There are some downsides though: (1) there is an extra 741network turnaround, (2) the algorithm needs to transmit some data to 742discover what difference type programs can discover locally (although 743this is only about 1% of the size of the files). 744 745b2. If one is willing to require that users use "cvs edit" before 746editing a file on the client side (in some cases, a development 747environment like emacs can make this fairly easy), then the Modified 748request in the protocol could be extended to allow the client to just 749send differences instead of entire files. In the degenerate case 750(e.g. "cvs diff" without arguments) the required network traffic is 751reduced to zero, and the client need not even contact the server. 752 753197. Analyze the difference between CVS_UNLINK & unlink_file. As far as I 754can tell, unlink_file aborts in noexec mode and CVS_UNLINK does not. I'm not 755sure it would be possible to remove even the use of temp files in noexec mode, 756but most unlinks should probably be using unlink_file and not CVS_UNLINK. 757 758198. Remove references to deprecated cvs_temp_name function. 759 760199. Add test for login & logout functionality, including support for 761backwards compatibility with old CVSROOTs. 762 763200. Make a 'cvs add' without write access a non-fatal error so that 764the user's Entries file is updated and future 'cvs diffs' will work 765properly. This should ease patch submission. 766 767201. cvs_temp_file should be creating temporary files in a privately owned 768subdirectory of of temp due to security issues on some systems. 769 770202. Enable rdiff to accept most diff options. Make rdiff output look 771like diff's. Make CVS diff garbage go to stderr and only standard diff 772output go to stdout. 773 774203. Add val-tags additions to the tagging code. Don't remove the 775update additions since val-tags could still be used as a cache when the 776repository was imported from elsewhere (the tags weren't applied with a 777version which wrote val-tags). 778 779204. Add test case for compression. A buf_shutdown error using compression 780wasn't caught by the test suite. 781 782205. There are lots of cases where trailing slashes on directory names 783and other non-canonical paths confuse CVS. Most of the cases that do 784work are handled on an ad-hoc basis. We need to come up with a coherent 785strategy to address path canonicalization and apply it consistently. 786 787208. Merge enhancements to the diff package back into the original GNU source. 788 789209. Go through this file and try to: 790 791 a. Verify that items are still valid. 792 793 b. Create test cases for valid items when they don't exist. 794 795 c. Remove fixed and no longer applicable items. 796 797210. Explain to sanity.sh how to deal with paths with spaces and other odd 798characters in them. 799 800211. Make sanity.sh run under the Win32 bash (cygwin) and maybe other Windex 801environments (e.g. DGSS or whatever the MSVC portability environemnt is called). 802 803212. Autotestify (see autoconf source) sanity.sh. 804 805213. Examine desirability of updating the regex library (regex.{c,h}) to the 806more recent versions that come with glibc and emacs. It might be worth waiting 807for the emacs folks to get their act together and merge their changes into the 808glibc version. 809 810214. Make options.h options configure script options instead. 811 812215. Add reditors and rwatchers commands. 813 814 - Is an r* command abstraction layer possible here for the commands 815 where this makes sense? Would it be simpler? It seems to me the 816 major operational differences lie in the file list construction. 817 818218. Fix "checkout -d ." in client/server mode. 819 820221. Handle spaces in file/directory names. (Most, if not all, of the 821internal infrastructure already handles them correctly, but most of the 822administrative file interfaces do not.) 823 824223. Internationalization support. This probably means using some kind 825of universal character set (ISO 10646?) internally and converting on 826input and output, which opens the locale can of worms. 827 828224. Better timezone handling. Many people would like to see times 829output in local time rather than UTC, but that's tricky since the 830conversion from internal form is currently done by the server who has no 831idea what the user's timezone even is, let alone the rules for 832converting to it. 833 834 - On the contrary, I think the MT server response should be easily adaptable 835for this purpose. It is defined in cvsclient.texi as processed by the client 836if it knows how and printed to stdout otherwise. A "time" tag or the like 837could be the usual CVS server UTC time string. An old client could just print 838the time in UTC and a new client would know that it could convert the time to a 839local time string according to the localization settings before printing it. 840 841225. Add support for --allow-root to server command. 842 843227. 'cvs release' should use the CVS/Root in the directory being released 844when such is specified rather than $CVSROOT. In my work directory with no CVS 845dir, a release of subdirectories causes the released projects to be tested 846against my $CVSROOT environment variable, which often isn't correct but which 847can complete without generating error messages if the project also exists in 848the other CVSROOT. This happens a lot with my copies of the ccvs project. 849 850228. Consider adding -d to commit ala ci. 851 852229. Improve the locking code to use a random delay with exponential 853backoff ala Ethernet and separate the notification interval from the 854wait interval. 855 856230. Support for options like compression as part of the CVSROOT might be 857nice. This should be fairly easy to implement now using the method options. 858 859234. Noop commands should be logged in the history file. Information can 860still be obtained with noop commands, for instance via `cvs -n up -p', and 861paranoid admins might appreciate this. Similarly, perhaps diff operations 862should be logged. 863