PageRenderTime 131ms CodeModel.GetById 28ms app.highlight 95ms RepoModel.GetById 1ms app.codeStats 0ms

#! | 862 lines | 697 code | 165 blank | 0 comment | 0 complexity | e3b86c7168935fa441b8a36cebaffc0b MD5 | raw file
Possible License(s): MPL-2.0-no-copyleft-exception, BSD-3-Clause, LGPL-2.0, LGPL-2.1, BSD-2-Clause, 0BSD, JSON, AGPL-1.0, GPL-2.0
  1The "TODO" file!                              -*-Indented-Text-*-
  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.
  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.
 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.
 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.
 3063. The "import" and vendor support commands (co -j) need to be documented
 31    better.
 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.
 3672. Consider re-design of the module -t options to use the file system more
 37    intuitively.
 3973. Consider an option (in .cvsrc?) to automatically add files that are new
 40    and specified to commit.
 4279. Might be nice to have some sort of interface to Sun's Translucent
 43    (?) File System and tagged revisions.
 4582. Maybe the import stuff should allow an arbitrary revision to be
 46    specified.
 4884. Improve the documentation about administration of the repository and
 49    how to add/remove files and the use of symbolic links.
 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.
 5693. Need to think hard about release and development environments.  Think
 57    about execsets as well.
 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.
 63100. Checked out files should have revision control support.  Maybe.
 65102. Perhaps directory modes should be propagated on all import check-ins.
 66     Not necessarily uid/gid changes.
 68103. setuid/setgid on files is suspect.
 70104. cvs should recover nicely on unreadable files/directories.
 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.
 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.
 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.
 92109. I had gotten pieces of the sys directory in the past but not a
 93     complete tree.  I just did something like:
 95        cvs get *
 97     Where sys was in * and got the message
 99        cvs get: Executing 'sys/tools/make_links sys'
100        sh: sys/tools/make_links: not found
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?
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).
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).
119123. Add a flag to import to not build vendor branches for local code.
120     (See `importb' tests in src/ for more details).
122124. Anyway, I thought you might want to add something like the following
123     to the cvs man pages:
125     BUGS
126 	The sum of the sizes of a module key and its contents are
127 	limited.  See ndbm(3).
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).
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.
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.
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).
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).
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 ]]
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.
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.
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.)
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.)
182145. After you create revision in the previous scenario, if
183     you do "cvs update -r1 filename" you get revision 1.1, not
184  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.
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.
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.
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).
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.
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.
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.
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).
238     (this item originally added 2 Feb 1992 but revised since).
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.
248     A new command seems appropriate for this.  The state can be saved in the
249     CVS directory.  I.e.,
251        % cvs message foo.c
252        Enter log message for foo.c
253        >> fixed an uninitialized variable
254        >> ^D
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).
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.
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).
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))?
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"
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.
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.)
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.
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.)
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
390179. "cvs admin" does not log its actions with loginfo, nor does it check
391     whether the action is allowed with commitinfo.  It should.
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!).
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
404 for an unofficial patch.
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.
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.
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:
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.
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).
437186.  There is a frequent discussion of multisite features.
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.
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).
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.
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.
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.
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.
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( 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).
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.
506189.  Renaming files and directories is a frequently discussed topic.
508Some of the problems with the status quo:
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.
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).
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).
524d.  Renaming directories is way too hard.
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.
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).
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.
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.
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.
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?
565Ideally, we'd come up with a way to parameterize the problem and
566simply write up a lookup table to determine the correct behavior.
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
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.
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:
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).
598  c.  Suppressing various error messages.  This is almost surely
599  bogus.
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)
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).
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:
657  cd /tmp
658  cvs -d /repos co foo
659  cd /
660  cvs update /tmp/foo
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:
666  cd /tmp/foo
667  cvs update .
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:
673  cd /tmp
674  cvs -d /repos1 co foo
675  cvs -d /repos2 co bar
676  cd /
677  cvs update /tmp/foo /tmp/bar
679To make that example work, we need to think hard about:
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.
688Because those issues are hairy, I suspect that having a change in
689CVSROOT be an error would be a better move.
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.
700Possible solutions:
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).
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.
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").
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.
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).
734b.  Cases in which the status quo does not send a diff (e.g. "cvs
737b1.  With some frequency, people suggest rsync or a similar algorithm
738(see  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).
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.
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.
758198.  Remove references to deprecated cvs_temp_name function.
760199.  Add test for login & logout functionality, including support for
761backwards compatibility with old CVSROOTs.
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.
767201.  cvs_temp_file should be creating temporary files in a privately owned
768subdirectory of of temp due to security issues on some systems.
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.
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).
779204.  Add test case for compression.  A buf_shutdown error using compression
780wasn't caught by the test suite.
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.
787208.  Merge enhancements to the diff package back into the original GNU source.
789209.  Go through this file and try to:
791  a.  Verify that items are still valid.
793  b.  Create test cases for valid items when they don't exist.
795  c.  Remove fixed and no longer applicable items.
797210.  Explain to how to deal with paths with spaces and other odd
798characters in them.
800211.  Make run under the Win32 bash (cygwin) and maybe other Windex
801environments (e.g. DGSS or whatever the MSVC portability environemnt is called).
803212.  Autotestify (see autoconf source)
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.
810214.  Make options.h options configure script options instead.
812215.  Add reditors and rwatchers commands.
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.
818218.  Fix "checkout -d ." in client/server mode.
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.)
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.
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.
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.
841225.  Add support for --allow-root to server command.
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.
850228.  Consider adding -d to commit ala ci.
852229.  Improve the locking code to use a random delay with exponential
853backoff ala Ethernet and separate the notification interval from the
854wait interval.
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.
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.