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