1 The "TODO" file! -*-Indented-Text-*-
3 22. Catch signals for cleanup when "add"ing files.
5 24. Insist on a log message.
6 (If done, this should be configurable via commitinfo or some new
7 config file -kingdon, Jun 1995).
9 30. Add "rdiff" program option to the modules database (and "diff"
10 too?). (perhaps should think a little harder about what this is
11 trying to accomplish and what the best way is -kingdon, Jul 1997).
13 31. Think hard about ^C recovery.
15 38. Think hard about using RCS state information to allow one to checkin
16 a new vendor release without having it be accessed until it has been
17 integrated into the local changes.
19 39. Think about a version of "cvs update -j" which remembers what from
20 that other branch is already merged. This has pitfalls--it could
21 easily lead to invisible state which could confuse users very
22 rapidly--but having to create a tag or some such mechanism to keep
23 track of what has been merged is a pain. Take a look at PRCS 1.2.
24 PRCS 1.0 was particularly bad the way it handled the "invisible
25 state", but 1.2 is significantly better.
27 45. Consider enhancing the "rdiff" and "tag" (rtag??) command support in
28 the module database -- they seem hard to use since these commands
29 deal directly with the RCS ,v files.
31 49. cvs xxx commands should be able to deal with files in other
32 directories. I want to do a cvs add foo/bar.c.
33 [[ most commands now use the generic recursion processor, but not all;
34 this note is left here to remind me to fix the others ]]
36 52. SCCS has a feature that I would *love* to see in CVS, as it is very
37 useful. One may make a private copy of SCCS suid to a particular user,
38 so other users in the authentication list may check files in and out of
39 a project directory without mucking about with groups. Is there any
40 plan to provide a similar functionality to CVS? Our site (and, I'd
41 imagine, many other sites with large user bases) has decided against
42 having the user-groups feature of unix available to the users, due to
43 perceived administrative, technical and performance headaches. A tool
44 such as CVS with features that provide group-like functionality would
47 62. Consider using revision controlled files and directories to handle the
48 new module format -- consider a cvs command front-end to
49 add/delete/modify module contents, maybe.
51 63. The "import" and vendor support commands (co -j) need to be documented
54 66. Length of the CVS temporary files must be limited to 14 characters for
55 System-V stupid support. As well as the length on the CVS.adm files.
57 72. Consider re-design of the module -o, -i, -t options to use the file
58 system more intuitively.
60 73. Consider an option (in .cvsrc?) to automatically add files that are new
61 and specified to commit.
63 79. Might be nice to have some sort of interface to Sun's Translucent
64 (?) File System and tagged revisions.
66 82. Maybe the import stuff should allow an arbitrary revision to be
69 84. Improve the documentation about administration of the repository and
70 how to add/remove files and the use of symbolic links.
72 85. Make symbolic links a valid thing to put under version control.
73 Perhaps use one of the tag fields in the RCS file? Note that we
74 can only support symlinks that are relative and within the scope of
75 the sources being controlled.
78 After a bit of soul searching via dbx, I realized my sin was that I'd
79 specified "echo" as the program to call from loginfo. The commit
80 procedure worked fine till it hit my echo, then silently aborted
81 leaving the lockfiles intact. Since I needn't use the loginfo
82 facility, I simply removed those commands and it all works.
84 93. Need to think hard about release and development environments. Think
85 about execsets as well.
87 98. If diff3 bombs out (too many differences) cvs then thinks that the file
88 has been updated and is OK to be commited even though the file
89 has not yet been merged.
91 100. Checked out files should have revision control support. Maybe.
93 102. Perhaps directory modes should be propagated on all import check-ins.
94 Not necessarily uid/gid changes.
96 103. setuid/setgid on files is suspect.
98 104. cvs should recover nicely on unreadable files/directories.
100 105. cvs should have administrative tools to allow for changing permissions
101 and modes and what not. In particular, this would make cvs a
102 more attractive alternative to rdist.
104 107. It should be possible to specify a list of symbolic revisions to
105 checkout such that the list is processed in reverse order looking for
106 matches within the RCS file for the symbolic revision. If there is
107 not a match, the next symbolic rev on the list is checked, and so on,
108 until all symbolic revs are exhausted. This would allow one to, say,
109 checkout "4.0" + "4.0.3" + "4.0.3Patch1" + "4.0.3Patch2" to get the
110 most recent 4.x stuff. This is usually handled by just specifying the
111 right release_tag, but most people forget to do this.
113 108. If someone creates a whole new directory (i.e. adds it to the cvs
114 repository) and you happen to have a directory in your source farm by
115 the same name, when you do your cvs update -d it SILENTLY does
116 *nothing* to that directory. At least, I think it was silent;
117 certainly, it did *not* abort my cvs update, as it would have if the
118 same thing had happened with a file instead of a directory.
120 109. I had gotten pieces of the sys directory in the past but not a
121 complete tree. I just did something like:
125 Where sys was in * and got the message
127 cvs get: Executing 'sys/tools/make_links sys'
128 sh: sys/tools/make_links: not found
130 I suspect this is because I didn't have the file in question,
131 but I do not understand how I could fool it into getting an
132 error. I think a later cvs get sys seemed to work so perhaps
133 something is amiss in handling multiple arguments to cvs get?
135 113. The "cvs update" command should tee its output to a log file in ".".
136 (why? What is wrong with piping stdout to "tee"? -kingdon, Jun 1995)
138 119. When importing a directory tree that is under SCCS/RCS control,
139 consider an option to have import checkout the SCCS/RCS files if
140 necessary. (This is if someone wants to import something which
141 is in RCS or SCCS without preserving the history, but makes sure
142 they do get the latest versions. It isn't clear to me how useful
143 that is -kingdon, June 1996).
145 122. If Name_Repository fails, it currently causes CVS to die completely. It
146 should instead return NULL and have the caller do something reasonable
147 (??? -what is reasonable? I'm not sure there is a real problem here.
148 -kingdon, June 1996).
150 123. Add a flag to import to not build vendor branches for local code.
151 (See `importb' tests in src/sanity.sh for more details).
153 124. Anyway, I thought you might want to add something like the following
154 to the cvs man pages:
157 The sum of the sizes of a module key and its contents are
158 limited. See ndbm(3).
160 126. Do an analysis to see if CVS is forgetting to close file descriptors.
161 Especially when committing many files (more than the open file limit
162 for the particular UNIX).
164 127. Look at *info files; they should all be quiet if the files are not
165 there. Should be able to point at a RCS directory and go.
167 130. cvs diff with no -r arguments does not need to look up the current RCS
168 version number since it only cares about what's in the Entries file.
169 This should make it much faster.
171 It should ParseEntries itself and access the entries list much like
172 Version_TS does (sticky tags and sticky options may need to be
173 supported here as well). Then it should only diff the things that
174 have the wrong time stamp (the ones that look modified).
176 134. Make a statement about using hard NFS mounts to your source
177 repository. Look into checking NULL fgets() returns with ferror() to
178 see if an error had occurred. (we should be checking for errors, quite
179 aside from NFS issues -kingdon, June 1996).
181 137. Some sites might want CVS to fsync() the RCS ,v file to protect
182 against nasty hardware errors. There is a slight performance hit with
183 doing so, though, so it should be configurable in the .cvsrc file.
184 Also, along with this, we should look at the places where CVS itself
185 could be a little more synchronous so as not to lose data.
186 [[ I've done some of this, but it could use much more ]]
188 138. Some people have suggested that CVS use a VPATH-like environment
189 variable to limit the amount of sources that need to be duplicated for
190 sites with giant source trees and no disk space.
192 141. Import should accept modules as its directory argument. If we're
193 going to implement this, we should think hard about how modules
194 might be expanded and how to handle those cases.
196 143. Update the documentation to show that the source repository is
197 something far away from the files that you work on. (People who
198 come from an RCS background are used to their `repository' being
199 _very_ close to their working directory.)
201 144. Have cvs checkout look for the environment variable CVSPREFIX
202 (or CVSMODPREFIX or some such). If it's set, then when looking
203 up an alias in the modules database, first look it up with the
204 value of CVSPREFIX attached, and then look for the alias itself.
205 This would be useful when you have several projects in a single
206 repository. You could have aliases abc_src and xyz_src and
207 tell people working on project abc to put "setenv CVSPREFIX abc_"
208 in their .cshrc file (or equivalent for other shells).
209 Then they could do "cvs co src" to get a copy of their src
210 directory, not xyz's. (This should create a directory called
213 145. After you create revision 1.1.1.1 in the previous scenario, if
214 you do "cvs update -r1 filename" you get revision 1.1, not
215 1.1.1.1. It would be nice to get the later revision. Again,
216 this restriction comes from RCS and is probably hard to
219 |"cvs update -r1 filename" does not tell RCS to follow any branches. CVS
220 |tries to be consistent with RCS in this fashion, so I would not change
221 |this. Within CVS we do have the flexibility of extending things, like
222 |making a revision of the form "-r1HEAD" find the most recent revision
223 |(branch or not) with a "1." prefix in the RCS file. This would get what
226 This would be very useful. Though I would prefer an option
227 such as "-v1" rather than "-r1HEAD". This option might be
230 146. The merging of files should be controlled via a hook so that programs
231 other than "rcsmerge" can be used, like Sun's filemerge or emacs's
232 emerge.el. (but be careful in making this work client/server--it means
233 doing the interactive merging at the end after the server is done).
234 (probably best is to have CVS do the non-interactive part and
235 tell the user about where the files are (.#foo.c.working and
236 .#foo.c.1.5 or whatever), so they can do the interactive part at
237 that point -kingdon, June 1996).
239 149. Maybe there should be an option to cvs admin that allows a user to
240 change the Repository/Root file with some degree of error checking?
241 Something like "cvs admin reposmv /old/path /new/pretty/path". Before
242 it does the replace it check to see that the files
243 /new/pretty/path/<dir>/<files> exist.
245 The obvious cases are where one moves the repository to another
246 machine or directory. But there are other cases, like where the
247 user might want to change from :pserver: to :ext:, use a different
248 server (if there are two server machines which share the
249 repository using a networked file system), etc.
251 The status quo is a bit of a mess (as of, say, CVS 1.9). It is
252 that the -d global option has two moderately different uses. One
253 is to use a totally different repository (in which case we'd
254 probably want to give an error if it disagreed with CVS/Root, as
255 CVS 1.8 and earlier did). The other is the "reposmv"
256 functionality above (in which the two repositories really are the
257 same, and we want to update the CVS/Root files). A related issue
258 is that the fact that CVS only sets and looks at the CVS/Root
259 file in the directory where CVS is run; it doesn't do anything
260 about CVS/Root files in subdirectories.
262 Note also RELATIVE_REPOS in options.h; it needs to be set for
263 changing CVS/Root (not CVS/Repository) to be sufficient in the
264 case where the directory has changed.
266 This whole area is a rather bad pile of individual decisions which
267 accumulated over time, some of them probably bad decisions with
268 hindsight. But we didn't get into this mess overnight, and we're
269 not going to get out of it overnight (that is, we need to come up
270 with a replacement behavior, document what parts of the status
271 quo are deprecated, probably circulate some unofficial patches, &c).
273 (this item originally added 2 Feb 1992 but revised since).
275 150. I have a customer request for a way to specify log message per
276 file, non-interactively before the commit, such that a single, fully
277 recursive commit prompts for one commit message, and concatenates the
278 per file messages for each file. In short, one commit, one editor
279 session, log messages allowed to vary across files within the commit.
280 Also, the per file messages should be allowed to be written when the
281 files are changed, which may predate the commit considerably.
283 A new command seems appropriate for this. The state can be saved in the
287 Enter log message for foo.c
288 >> fixed an uninitialized variable
291 The text is saved as CVS/foo.c,m (or some such name) and commit
292 is modified to append (prepend?) the text (if found) to the log
293 message specified at commit time. Easy enough. (having cvs
294 commit be non-interactive takes care of various issues like
295 whether to connect to the server before or after prompting for a
296 message (see comment in commit.c at call to start_server). Also
297 would clean up the kludge for what to do with the message from
298 do_editor if the up-to-date check fails (see commit.c client code).
300 I'm not sure about the part above about having commit prompt
301 for an overall message--part of the point is having commit
302 non-interactive and somehow combining messages seems like (excess?)
305 Would be nice to do this so it allows users more flexibility in
306 specifying messages per-directory ("cvs message -l") or per-tree
307 ("cvs message") or per-file ("cvs message foo.c"), and fixes the
308 incompatibility between client/server (per-tree) and
309 non-client/server (per-directory).
311 A few interesting issues with this: (1) if you do a cvs update or
312 some other operation which changes the working directory, do you
313 need to run "cvs message" again (it would, of course, bring up
314 the old message which you could accept)? Probably yes, after all
315 merging in some conflicts might change the situation. (2) How do
316 you change the stored messages if you change your mind before the
317 commit (probably run "cvs message" again, as hinted in (1))?
319 151. Also, is there a flag I am missing that allows replacing Ulrtx_Build
320 by Ultrix_build? I.E. I would like a tag replacement to be a one step
321 operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build"
322 followed by "cvs rtag -d Ulrtx_Build"
324 152. The "cvs -n" option does not work as one would expect for all the
325 commands. In particular, for "commit" and "import", where one would
326 also like to see what it would do, without actually doing anything.
328 153. There should be some command (maybe I just haven't figured out
329 which one...) to import a source directory which is already
330 RCS-administered without losing all prior RCS gathered data.
331 Thus, it would have to examine the RCS files and choose a
332 starting version and branch higher than previous ones used.
333 (Check out rcs-to-cvs and see if it addresses this issue.)
335 154. When committing the modules file, a pre-commit check should be done to
336 verify the validity of the new modules file before allowing it to be
339 155. The options for "cvs history" are mutually exclusive, even though
340 useful queries can be done if they are not, as in specifying both
341 a module and a tag. A workaround is to specify the module, then
342 run the output through grep to only display lines that begin with
343 T, which are tag lines. (Better perhaps if we redesign the whole
344 "history" business -- check out doc/cvs.texinfo for the entire
347 156. Also, how hard would it be to allow continuation lines in the
348 {commit,rcs,log}info files? It would probably be useful with all of
349 the various flags that are now available, or if somebody has a lot of
350 files to put into a module.
352 158. If I do a recursive commit and find that the same RCS file is checked
353 out (and modified!) in two different places within my checked-out
354 files (but within the realm of a single "commit"), CVS will commit the
355 first change, then overwrite that change with the second change. We
356 should catch this (typically unusual) case and issue an appropriate
359 160. The checks that the commit command does should be extended to make
360 sure that the revision that we will lock is not already locked by
361 someone else. Maybe it should also lock the new revision if the old
362 revision was already locked by the user as well, thus moving the lock
363 forward after the commit.
365 163. The rtag/tag commands should have an option that removes the specified
366 tag from any file that is in the attic. This allows one to re-use a
367 tag (like "Mon", "Tue", ...) all the time and still have it tag the
370 165. The "import" command will create RCS files automatically, but will
371 screw-up when trying to create long file names on short file name
372 file systems. Perhaps import should be a bit more cautious.
374 166. There really needs to be a "Getting Started" document which describes
375 some of the new CVS philosophies. Folks coming straight from SCCS or
376 RCS might be confused by "cvs import". Also need to explain:
377 - How one might setup their $CVSROOT
378 - What all the tags mean in an "import" command
379 - Tags are important; revision numbers are not
381 170. Is there an "info" file that can be invoked when a file is checked out, or
382 updated ? What I want to do is to advise users, particularly novices, of
383 the state of their working source whenever they check something out, as
386 For example, I've written a perl script which tells you what branch you're
387 on, if any. Hopefully this will help guard against mistaken checkins to
388 the trunk, or to the wrong branch. I suppose I can do this in
389 "commitinfo", but it'd be nice to advise people before they edit their
392 It would also be nice if there was some sort of "verboseness" switch to
393 the checkout and update commands that could turn this invocation of the
394 script off, for mature users.
396 173. We have a tagged branch in CVS. How do we get the version of that branch
397 (for an entire directory) that corresponds to the files on that branch on a
398 certain day? I'd like to specify BOTH -r and -D to 'cvs checkout', but I
399 can't. It looks like I can only specify the date for the main line (as
400 opposed to any branches). True? Any workarounds to get what I need?
402 174. I would like to see "cvs release" modified so that it only removes files
403 which are known to CVS - all the files in the repository, plus those which
404 are listed in .cvsignore. This way, if you do leave something valuable in
405 a source tree you can "cvs release -d" the tree and your non-CVS goodies
406 are still there. If a user is going to leave non-CVS files in their source
407 trees, they really should have to clean them up by hand.
409 175. And, in the feature request department, I'd dearly love a command-line
410 interface to adding a new module to the CVSROOT/modules file.
412 176. If you use the -i flag in the modules file, you can control access
413 to source code; this is a Good Thing under certain circumstances. I
414 just had a nasty thought, and on experiment discovered that the
415 filter specified by -i is _not_ run before a cvs admin command; as
416 this allows a user to go behind cvs's back and delete information
417 (cvs admin -o1.4 file) this seems like a serious problem.
419 177. We've got some external vendor source that sits under a source code
420 hierarchy, and when we do a cvs update, it gets wiped out because
421 its tag is different from the "main" distribution. I've tried to
422 use "-I" to ignore the directory, as well as .cvsignore, but this
425 179. "cvs admin" does not log its actions with loginfo, nor does it check
426 whether the action is allowed with commitinfo. It should.
428 180. "cvs edit" should show you who is already editing the files,
429 probably (that is, do "cvs editors" before executing, or some
430 similar result). (But watch out for what happens if the network
433 182. There should be a way to show log entries corresponding to
434 changes from tag "foo" to tag "bar". "cvs log -rfoo:bar" doesn't cut
435 it, because it erroneously shows the changes associated with the
436 change from the revision before foo to foo. I'm not sure that is ever
437 a useful or logical behavior ("cvs diff -r foo -r bar" gets this
438 right), but is compatibility an issue? See
439 http://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch.
441 183. "cvs status" should report on Entries.Static flag and CVS/Tag (how?
442 maybe a "cvs status -d" to give directory status?). There should also
443 be more documentation of how these get set and how/when to re-set them.
445 184. Would be nice to implement the FreeBSD MD5-based password hash
446 algorithm in pserver. For more info see "6.1. DES, MD5, and Crypt" in
447 the FreeBSD Handbook, and src/lib/libcrypt/crypt.c in the FreeBSD
448 sources. Certainly in the context of non-unix servers this algorithm
449 makes more sense than the traditional unix crypt() algorithm, which
450 suffers from export control problems.
452 185. A frequent complaint is that keyword expansion causes conflicts
453 when merging from one branch to another. The first step is
454 documenting CVS's existing features in this area--what happens with
455 various -k options in various places? The second step is thinking
456 about whether there should be some new feature and if so how it should
457 be designed. For example, here is one thought:
459 rcs' co command needs a new -k option. The new option should expand
460 $Log entries without expanding $Revision entries. This would
461 allow cvs to use rcsmerge in such a way that joining branches into
462 main lines would neither generate extra collisions on revisions nor
465 The details of this are out of date (CVS no longer invokes "co", and
466 any changes in this area would be done by bypassing RCS rather than
467 modifying it), but even as to the general idea, I don't have a clear
468 idea about whether it would be good (see what I mean about the need
469 for better documentation? I work on CVS full-time, and even I don't
470 understand the state of the art on this subject).
472 186. There is a frequent discussion of multisite features.
474 * There may be some overlap with the client/server CVS, which is good
475 especially when there is a single developer at each location. But by
476 "multisite" I mean something in which each site is more autonomous, to
477 one extent or another.
479 * Vendor branches are the closest thing that CVS currently has for
480 multisite features. They have fixable drawbacks (such as poor
481 handling of added and removed files), and more fundamental drawbacks
482 (when you import a vendor branch, you are importing a set of files,
483 not importing any knowledge of their version history outside the
486 * One approach would be to require checkins (or other modifications to
487 the repository) to succeed at a write quorum of sites (51%) before
488 they are allowed to complete. To work well, the network should be
489 reliable enough that one can typically get to that many sites. When a
490 server which has been out of touch reconnects, it would want to update
491 its data before doing anything else. Any of the servers can service
492 all requests locally, except perhaps for a check that they are
493 up-to-date. The way this differs from a run-of-the-mill distributed
494 database is that if one only allows reversible operations via this
495 mechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site
496 can back up the others, such that failures at one site, including
497 something like deleting all the sources, can be recovered from. Thus
498 the sites need not trust each other as much as for many shared
499 databases, and the system may be resilient to many types of
500 organizational failures. Sometimes I call this design the
503 * Another approach is a master/slave one. Checkins happen at the
504 master site, and slave sites need to check whether their local
505 repository is up to date before relying on its information.
507 * Another approach is to have each site own a particular branch. This
508 one is the most tolerant of flaky networks; if checkins happen at each
509 site independently there is no particular problem. The big question
510 is whether merges happen only manually, as with existing CVS branches,
511 or whether there is a feature whereby there are circumstances in which
512 merges from one branch to the other happen automatically (for example,
513 the case in which the branches have not diverged). This might be a
514 legitimate question to ask even quite aside from multisite features.
516 One additional random tidbit is to note that Eric Raymond has some
517 interest in this sort of thing. The item "Cooperative distributed
518 freeware development" on http://www.ccil.org/~esr/ has a very brief
519 introduction to what he is thinking about.
521 187. Might want to separate out usage error messages and help
522 messages. The problem now is that if you specify an invalid option,
523 for example, the error message is lost among all the help text. In
524 the new regime, the error message would be followed by a one-line
525 message directing people to the appropriate help option ("cvs -H
526 <command>" or "cvs --help-commands" or whatever, according to the
527 situation). I'm not sure whether this change would be controversial
528 (as defined in HACKING), so there might be a need for further
529 discussion or other actions other than just coding.
531 188. Option parsing and .cvsrc has at least one notable limitation.
532 If you want to set a global option only for some CVS commands, there
533 is no way to do it (for example, if one wants to set -q only for
534 "rdiff"). I am told that the "popt" package from RPM
535 (http://www.rpm.org) could solve this and other problems (for example,
536 if the syntax of option stuff in .cvsrc is similar to RPM, that would
537 be great from a user point of view). It would at least be worth a
538 look (it also provides a cleaner API than getopt_long).
540 Another issue which may or may not be related is the issue of
541 overriding .cvsrc from the command line. The cleanest solution might
542 be to have options in mutually exclusive sets (-l/-R being a current
543 example, but --foo/--no-foo is a better way to name such options). Or
544 perhaps there is some better solution.
546 189. Renaming files and directories is a frequently discussed topic.
548 Some of the problems with the status quo:
550 a. "cvs annotate" cannot operate on both the old and new files in a
551 single run. You need to run it twice, once for the new name and once
554 b. "cvs diff" (or "cvs diff -N") shows a rename as a removal of the
555 old file and an addition of the new one. Some people would like to
556 see the differences between the file contents (but then how would we
557 indicate the fact that the file has been renamed? Certainly the
558 notion that "patch(1)" has of renames is as a removal and addition).
560 c. "cvs log" should be able to show the changes between two
561 tags/dates, even in the presence of adds/removes/renames (I'm not sure
562 what the status quo is on this; see also item #182).
564 d. Renaming directories is way too hard.
568 It is perhaps premature to try to design implementation details
569 without answering some of the above questions about desired behaviors
570 but several general implementations get mentioned.
572 i. No fundamental changes (for example, a "cvs rename" command which
573 operated on directories could still implement the current recommended
574 practice for renaming directories, which is to rename each of the
575 files contained therein via an add and a remove). One thing to note
576 that the status quo gets right is proper merges, even with adds and
577 removals (Well, mostly right at least. There are a *LOT* of different
578 cases; see the testsuite for some of them).
580 ii. Rename database. In this scheme the files in the repository
581 would have some arbitrary name, and then a separate rename database
582 would indicate the current correspondence between the filename in the
583 working directory and the actual storage. As far as I know this has
584 never been designed in detail for CVS.
586 iii. A modest change in which the RCS files would contain some
587 information such as "renamed from X" or "renamed to Y". That is, this
588 would be generally similar to the log messages which are suggested
589 when one renames via an add and a removal, but would be
590 computer-parseable. I don't think anyone has tried to flesh out any
593 It is interesting to note that in solution ii. version numbers in the
594 "new file" start where the "old file" left off, while in solutions
595 i. and iii., version numbers restart from 1.1 each time a file is
596 renamed. Except perhaps in the case where we rename a file from foo
597 to bar and then back to foo. I'll shut up now.
599 Regardless of the method we choose, we need to address how renames
600 affect existing CVS behaviors. For example, what happens when you
601 rename a file on a branch but not the trunk and then try to merge the
602 two? What happens when you rename a file on one branch and delete it
603 on another and try to merge the two?
605 Ideally, we'd come up with a way to parameterize the problem and
606 simply write up a lookup table to determine the correct behavior.
608 190. The meaning of the -q and -Q global options is very ad hoc;
609 there is no clear definition of which messages are suppressed by them
610 and which are not. Here is a classification of the current meanings
611 of -q; I don't know whether anyone has done a similar investigation of
614 a. The "warm fuzzies" printed upon entering each directory (for
615 example, "cvs update: Updating sdir"). The need for these messages
616 may be decreased now that most of CVS uses ->fullname instead of
617 ->file in messages (a project which is *still* not 100% complete,
618 alas). However, the issue of whether CVS can offer status as it
619 runs is an important one. Of course from the command line it is
620 hard to do this well and one ends up with options like -q. But
621 think about emacs, jCVS, or other environments which could flash you
622 the latest status line so you can see whether the system is working
625 b. Other cases where the message just offers information (rather
626 than an error) and might be considered unnecessarily verbose. These
627 have a certain point to them, although it isn't really clear whether
628 it should be the same option as the warm fuzzies or whether it is
629 worth the conceptual hair:
631 add.c: scheduling %s `%s' for addition (may be an issue)
632 modules.c: %s %s: Executing '%s' (I can see how that might be noise,
634 remove.c: scheduling `%s' for removal (analogous to the add.c one)
635 update.c: Checking out %s (hmm, that message is a bit on the noisy side...)
636 (but the similar message in annotate is not affected by -q).
638 c. Suppressing various error messages. This is almost surely
641 commit.c: failed to remove tag `%s' from `%s' (Questionable.
642 Rationale might be that we already printed another message
643 elsewhere but why would it be necessary to avoid
644 the extra message in such an uncommon case?)
645 commit.c: failed to check out `%s' (likewise; this one seems to be a
646 vestige from before RCS_checkout was internal. Take a look at how
647 RCS_checkout handles errors)
648 commit.c: failed to commit dead revision for `%s' (likewise)
649 remove.c: file `%s' still in working directory (see below about rm
651 remove.c: nothing known about `%s' (looks dubious to me, especially in
652 the case where the user specified it explicitly).
653 remove.c: removed `%s' (seems like an obscure enough case that I fail
654 to see the appeal of being cryptically concise here).
655 remove.c: file `%s' already scheduled for removal (now it is starting
656 to look analogous to the infamous rm -f option).
657 rtag.c: cannot find tag `%s' in `%s' (more rm -f like behavior)
658 rtag.c: failed to remove tag `%s' from `%s' (ditto)
659 tag.c: failed to remove tag %s from %s (see above about whether RCS_*
660 has already printed an error message).
661 tag.c: couldn't tag added but un-commited file `%s' (more rm -f
663 tag.c: skipping removed but un-commited file `%s' (ditto)
664 tag.c: cannot find revision control file for `%s' (ditto, but at first
665 glance seems even worse, as this would seem to be a "can't happen"
668 191. Storing RCS files, especially binary files, takes rather more
669 space than it could, typically.
670 - The virtue of the status quo is that it is simple to implement.
671 Of course it is also simplest in terms of dealing with compatibility.
672 - Just storing the revisions as separate gzipped files is a common
673 technique. It also is pretty simple (no new algorithms, CVS
674 already has zlib around). Of course for some files (such as files
675 which are already compressed) the gzip step won't help, but
676 something which can at least sometimes avoid rewriting the entire
677 RCS file for each new revision would, I would think, be a big
678 speedup for large files.
679 - Josh MacDonald has written a tool called xdelta which produces
680 differences (that is, sufficient information to transform the old
681 to the new) which looks for common sequences of bytes, like RCS
682 currently does, but which is not based on lines. This seems to do
683 quite well for some kinds of files (e.g. FrameMaker documents,
684 text files), and not as well for others (anything which is already
685 compressed, executables). xdelta 1.10 also is faster than GNU diff.
686 - Karl Fogel has thought some about using a difference technique
687 analogous to fractal compression (see the comp.compression FAQ for
688 more on fractal compression, including at least one patent to
689 watch for; I don't know how analogous Karl's ideas are to the
690 techniques described there).
691 - Quite possibly want some documented interface by which a site can
692 plug in their choice of external difference programs (with the
693 ability to choose the program based on filename, magic numbers,
696 192. "cvs update" using an absolute pathname does not work if the
697 working directory is not a CVS-controlled directory with the correct
698 CVSROOT. For example, the following will fail:
705 It is possible to read the CVSROOT from the administrative files in
706 the directory specified by the absolute pathname argument to update.
707 In that case, the last command above would be equivalent to:
712 This can be problematic, however, if we ask CVS to update two
713 directories with different CVSROOTs. Currently, CVS has no way of
714 changing CVSROOT mid-stream. Consider the following:
717 cvs -d /repos1 co foo
718 cvs -d /repos2 co bar
720 cvs update /tmp/foo /tmp/bar
722 To make that example work, we need to think hard about:
724 - where and when CVSROOT-related variables get set
725 - who caches said variables for later use
726 - how the remote protocol should be extended to handle sending a new
727 repository mid-stream
728 - how the client should maintain connections to a variety of servers
729 in a single invocation.
731 Because those issues are hairy, I suspect that having a change in
732 CVSROOT be an error would be a better move.
734 193. The client relies on timestamps to figure out whether a file is
735 (maybe) modified. If something goes awry, then it ends up sending
736 entire files to the server to be checked, and this can be quite slow
737 especially over a slow network. A couple of things that can happen:
738 (a) other programs, like make, use timestamps, so one ends up needing
739 to do "touch foo" and otherwise messing with timestamps, (b) changing
740 the timezone offset (e.g. summer vs. winter or moving a machine)
741 should work on unix, but there may be problems with non-unix.
745 a. Store a checksum for each file in CVS/Entries or some such
746 place. What to do about hash collisions is interesting: using a
747 checksum, like MD5, large enough to "never" have collisions
748 probably works in practice (of course, if there is a collision then
749 all hell breaks loose because that code path was not tested, but
750 given the tiny, tiny probability of that I suppose this is only an
753 b. I'm not thinking of others, except storing the whole file in
754 CVS/Base, and I'm sure using twice the disk space would be
757 194. CVS does not separate the "metadata" from the actual revision
758 history; it stores them both in the RCS files. Metadata means tags
759 and header information such as the number of the head revision.
760 Storing the metadata separately could speed up "cvs tag" enormously,
761 which is a big problem for large repositories. It could also probably
762 make CVS's locking much less in the way (see comment in do_recursion
763 about "two-pass design").
765 195. Many people using CVS over a slow link are interested in whether
766 the remote protocol could be any more efficient with network
767 bandwidth. This item is about one aspect of that--how the server
768 sends a new version of a file the client has a different version of,
771 a. Cases in which the status quo already sends a diff. For most text
772 files, this is probably already close to optimal. For binary files,
773 and anomalous text files, it might be worth looking into other
774 difference algorithms (see item #191).
776 b. Cases in which the status quo does not send a diff (e.g. "cvs
779 b1. With some frequency, people suggest rsync or a similar algorithm
780 (see ftp://samba.anu.edu.au/pub/rsync/). This could speed things up,
781 and in some ways involves the most minimal changes to the default CVS
782 paradigm. There are some downsides though: (1) there is an extra
783 network turnaround, (2) the algorithm is not as efficient with network
784 bandwidth as difference type programs (it transmits a fair bit of data
785 to discover what a difference program discovers locally).
787 b2. If one is willing to require that users use "cvs edit" before
788 editing a file on the client side (in some cases, a development
789 environment like emacs can make this fairly easy), then the Modified
790 request in the protocol could be extended to allow the client to just
791 send differences instead of entire files. In the degenerate case
792 (e.g. "cvs diff" without arguments) the required network traffic is
793 reduced to zero, and the client need not even contact the server.
projects / FreeBSD / FreeBSD.git / blob