"Fossies" - the Fresh Open Source Software Archive

Member "cvs-1.11.23/TODO" (25 Aug 2006, 43268 Bytes) of package /linux/misc/old/cvs-1.11.23.tar.gz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 The "TODO" file!                              -*-Indented-Text-*-
    3 38. 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.
    7 39. 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.
   15 52. 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.
   26 62. 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.
   30 63. The "import" and vendor support commands (co -j) need to be documented
   31     better.
   33 66. 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.
   36 72. Consider re-design of the module -t options to use the file system more
   37     intuitively.
   39 73. Consider an option (in .cvsrc?) to automatically add files that are new
   40     and specified to commit.
   42 79. Might be nice to have some sort of interface to Sun's Translucent
   43     (?) File System and tagged revisions.
   45 82. Maybe the import stuff should allow an arbitrary revision to be
   46     specified.
   48 84. Improve the documentation about administration of the repository and
   49     how to add/remove files and the use of symbolic links.
   51 85. 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.
   56 93. Need to think hard about release and development environments.  Think
   57     about execsets as well.
   59 98. 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.
   63 100. Checked out files should have revision control support.  Maybe.
   65 102. Perhaps directory modes should be propagated on all import check-ins.
   66      Not necessarily uid/gid changes.
   68 103. setuid/setgid on files is suspect.
   70 104. cvs should recover nicely on unreadable files/directories.
   72 105. 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.
   76 107. 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.
   85 108. 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.
   92 109. 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?
  107 119. 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).
  114 122. 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).
  119 123. Add a flag to import to not build vendor branches for local code.
  120      (See `importb' tests in src/sanity.sh for more details).
  122 124. 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).
  129 126. 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).
  133 127. 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.
  136 130. 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).
  145 134. 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).
  150 137. 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 ]]
  157 138. 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.
  161 141. 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.
  165 143. 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.)
  170 144. 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.)
  182 145. 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.
  199 146. 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).
  208 149. 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).
  240 150. 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))?
  284 151. 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"
  289 152. 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.
  293 153. 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.)
  300 154. 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.
  304 155. 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.)
  312 156. 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.
  317 158. 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.
  324 160. 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.
  330 163. 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.
  335 165. 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.
  339 166. 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
  346 170. 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.
  361 173. 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.
  367 174. 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.
  374 175. 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.
  377 176. 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.
  384 177. 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.
  390 179. "cvs admin" does not log its actions with loginfo, nor does it check
  391      whether the action is allowed with commitinfo.  It should.
  393 180. "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!).
  398 182.  There should be a way to show log entries corresponding to
  399 changes from tag "foo" to tag "bar".  "cvs log -rfoo:bar" doesn't cut
  400 it, because it erroneously shows the changes associated with the
  401 change from the revision before foo to foo.  I'm not sure that is ever
  402 a useful or logical behavior ("cvs diff -r foo -r bar" gets this
  403 right), but is compatibility an issue?  See
  404 http://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch.
  406 183.  "cvs status" should report on Entries.Static flag and CVS/Tag (how?
  407 maybe a "cvs status -d" to give directory status?).  There should also
  408 be more documentation of how these get set and how/when to re-set them.
  410 184.  Would be nice to implement the FreeBSD MD5-based password hash
  411 algorithm in pserver.  For more info see "6.1. DES, MD5, and Crypt" in
  412 the FreeBSD Handbook, and src/lib/libcrypt/crypt.c in the FreeBSD
  413 sources.  Certainly in the context of non-unix servers this algorithm
  414 makes more sense than the traditional unix crypt() algorithm, which
  415 suffers from export control problems.
  417 185.  A frequent complaint is that keyword expansion causes conflicts
  418 when merging from one branch to another.  The first step is
  419 documenting CVS's existing features in this area--what happens with
  420 various -k options in various places?  The second step is thinking
  421 about whether there should be some new feature and if so how it should
  422 be 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.
  430 The details of this are out of date (CVS no longer invokes "co", and
  431 any changes in this area would be done by bypassing RCS rather than
  432 modifying it), but even as to the general idea, I don't have a clear
  433 idea about whether it would be good (see what I mean about the need
  434 for better documentation?  I work on CVS full-time, and even I don't
  435 understand the state of the art on this subject).
  437 186.  There is a frequent discussion of multisite features.
  439 * There may be some overlap with the client/server CVS, which is good
  440 especially when there is a single developer at each location.  But by
  441 "multisite" I mean something in which each site is more autonomous, to
  442 one extent or another.
  444 * Vendor branches are the closest thing that CVS currently has for
  445 multisite features.  They have fixable drawbacks (such as poor
  446 handling of added and removed files), and more fundamental drawbacks
  447 (when you import a vendor branch, you are importing a set of files,
  448 not importing any knowledge of their version history outside the
  449 current repository).
  451 * One approach would be to require checkins (or other modifications to
  452 the repository) to succeed at a write quorum of sites (51%) before
  453 they are allowed to complete.  To work well, the network should be
  454 reliable enough that one can typically get to that many sites.  When a
  455 server which has been out of touch reconnects, it would want to update
  456 its data before doing anything else.  Any of the servers can service
  457 all requests locally, except perhaps for a check that they are
  458 up-to-date.  The way this differs from a run-of-the-mill distributed
  459 database is that if one only allows reversible operations via this
  460 mechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site
  461 can back up the others, such that failures at one site, including
  462 something like deleting all the sources, can be recovered from.  Thus
  463 the sites need not trust each other as much as for many shared
  464 databases, and the system may be resilient to many types of
  465 organizational failures.  Sometimes I call this design the
  466 "CVScluster" design.
  468 * Another approach is a master/slave one.  Checkins happen at the
  469 master site, and slave sites need to check whether their local
  470 repository is up to date before relying on its information.
  472 * Another approach is to have each site own a particular branch.  This
  473 one is the most tolerant of flaky networks; if checkins happen at each
  474 site independently there is no particular problem.  The big question
  475 is whether merges happen only manually, as with existing CVS branches,
  476 or whether there is a feature whereby there are circumstances in which
  477 merges from one branch to the other happen automatically (for example,
  478 the case in which the branches have not diverged).  This might be a
  479 legitimate question to ask even quite aside from multisite features.
  481 187.  Might want to separate out usage error messages and help
  482 messages.  The problem now is that if you specify an invalid option,
  483 for example, the error message is lost among all the help text.  In
  484 the new regime, the error message would be followed by a one-line
  485 message directing people to the appropriate help option ("cvs -H
  486 <command>" or "cvs --help-commands" or whatever, according to the
  487 situation).  I'm not sure whether this change would be controversial
  488 (as defined in HACKING), so there might be a need for further
  489 discussion or other actions other than just coding.
  491 188.  Option parsing and .cvsrc has at least one notable limitation.
  492 If you want to set a global option only for some CVS commands, there
  493 is no way to do it (for example, if one wants to set -q only for
  494 "rdiff").  I am told that the "popt" package from RPM
  495 (http://www.rpm.org) could solve this and other problems (for example,
  496 if the syntax of option stuff in .cvsrc is similar to RPM, that would
  497 be great from a user point of view).  It would at least be worth a
  498 look (it also provides a cleaner API than getopt_long).
  500 Another issue which may or may not be related is the issue of
  501 overriding .cvsrc from the command line.  The cleanest solution might
  502 be to have options in mutually exclusive sets (-l/-R being a current
  503 example, but --foo/--no-foo is a better way to name such options).  Or
  504 perhaps there is some better solution.
  506 189.  Renaming files and directories is a frequently discussed topic.
  508 Some of the problems with the status quo:
  510 a.  "cvs annotate" cannot operate on both the old and new files in a
  511 single run.  You need to run it twice, once for the new name and once
  512 for the old name.
  514 b.  "cvs diff" (or "cvs diff -N") shows a rename as a removal of the
  515 old file and an addition of the new one.  Some people would like to
  516 see the differences between the file contents (but then how would we
  517 indicate the fact that the file has been renamed?  Certainly the
  518 notion that "patch(1)" has of renames is as a removal and addition).
  520 c.  "cvs log" should be able to show the changes between two
  521 tags/dates, even in the presence of adds/removes/renames (I'm not sure
  522 what the status quo is on this; see also item #182).
  524 d.  Renaming directories is way too hard.
  526 Implementations:
  528 It is perhaps premature to try to design implementation details
  529 without answering some of the above questions about desired behaviors
  530 but several general implementations get mentioned.
  532 i.  No fundamental changes (for example, a "cvs rename" command which
  533 operated on directories could still implement the current recommended
  534 practice for renaming directories, which is to rename each of the
  535 files contained therein via an add and a remove).  One thing to note
  536 that the status quo gets right is proper merges, even with adds and
  537 removals (Well, mostly right at least.  There are a *LOT* of different
  538 cases; see the testsuite for some of them).
  540 ii.  Rename database.  In this scheme the files in the repository
  541 would have some arbitrary name, and then a separate rename database
  542 would indicate the current correspondence between the filename in the
  543 working directory and the actual storage.  As far as I know this has
  544 never been designed in detail for CVS.
  546 iii.  A modest change in which the RCS files would contain some
  547 information such as "renamed from X" or "renamed to Y".  That is, this
  548 would be generally similar to the log messages which are suggested
  549 when one renames via an add and a removal, but would be
  550 computer-parseable.  I don't think anyone has tried to flesh out any
  551 details here either.
  553 It 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
  555 i. and iii., version numbers restart from 1.1 each time a file is
  556 renamed.  Except perhaps in the case where we rename a file from foo
  557 to bar and then back to foo.  I'll shut up now.
  559 Regardless of the method we choose, we need to address how renames
  560 affect existing CVS behaviors.  For example, what happens when you
  561 rename a file on a branch but not the trunk and then try to merge the
  562 two?  What happens when you rename a file on one branch and delete it
  563 on another and try to merge the two?
  565 Ideally, we'd come up with a way to parameterize the problem and
  566 simply write up a lookup table to determine the correct behavior.
  568 190.  The meaning of the -q and -Q global options is very ad hoc;
  569 there is no clear definition of which messages are suppressed by them
  570 and which are not.  Here is a classification of the current meanings
  571 of -q; I don't know whether anyone has done a similar investigation of
  572 -Q:
  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)
  625 191.  Storing RCS files, especially binary files, takes rather more
  626 space 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).
  653 192.  "cvs update" using an absolute pathname does not work if the
  654 working directory is not a CVS-controlled directory with the correct
  655 CVSROOT.  For example, the following will fail:
  657   cd /tmp
  658   cvs -d /repos co foo
  659   cd /
  660   cvs update /tmp/foo
  662 It is possible to read the CVSROOT from the administrative files in
  663 the directory specified by the absolute pathname argument to update.
  664 In that case, the last command above would be equivalent to:
  666   cd /tmp/foo
  667   cvs update .
  669 This can be problematic, however, if we ask CVS to update two
  670 directories with different CVSROOTs.  Currently, CVS has no way of
  671 changing 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
  679 To 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.
  688 Because those issues are hairy, I suspect that having a change in
  689 CVSROOT be an error would be a better move.
  691 193.  The client relies on timestamps to figure out whether a file is
  692 (maybe) modified.  If something goes awry, then it ends up sending
  693 entire files to the server to be checked, and this can be quite slow
  694 especially over a slow network.  A couple of things that can happen:
  695 (a) other programs, like make, use timestamps, so one ends up needing
  696 to do "touch foo" and otherwise messing with timestamps, (b) changing
  697 the timezone offset (e.g. summer vs. winter or moving a machine)
  698 should work on unix, but there may be problems with non-unix.
  700 Possible 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.
  714 194.  CVS does not separate the "metadata" from the actual revision
  715 history; it stores them both in the RCS files.  Metadata means tags
  716 and header information such as the number of the head revision.
  717 Storing the metadata separately could speed up "cvs tag" enormously,
  718 which is a big problem for large repositories.  It could also probably
  719 make CVS's locking much less in the way (see comment in do_recursion
  720 about "two-pass design").
  722 195.  Many people using CVS over a slow link are interested in whether
  723 the remote protocol could be any more efficient with network
  724 bandwidth.  This item is about one aspect of that--how the server
  725 sends a new version of a file the client has a different version of,
  726 or vice versa.
  728 a.  Cases in which the status quo already sends a diff.  For most text
  729 files, this is probably already close to optimal.  For binary files,
  730 and anomalous (?) text files (e.g. those in which it would help to do
  731 moves, as well as adds and deletes), it might be worth looking into other
  732 difference algorithms (see item #191).
  734 b.  Cases in which the status quo does not send a diff (e.g. "cvs
  735 commit").
  737 b1.  With some frequency, people suggest rsync or a similar algorithm
  738 (see ftp://samba.anu.edu.au/pub/rsync/).  This could speed things up,
  739 and in some ways involves the most minimal changes to the default CVS
  740 paradigm.  There are some downsides though: (1) there is an extra
  741 network turnaround, (2) the algorithm needs to transmit some data to
  742 discover what difference type programs can discover locally (although
  743 this is only about 1% of the size of the files).
  745 b2.  If one is willing to require that users use "cvs edit" before
  746 editing a file on the client side (in some cases, a development
  747 environment like emacs can make this fairly easy), then the Modified
  748 request in the protocol could be extended to allow the client to just
  749 send differences instead of entire files.  In the degenerate case
  750 (e.g. "cvs diff" without arguments) the required network traffic is
  751 reduced to zero, and the client need not even contact the server.
  753 197.  Analyze the difference between CVS_UNLINK & unlink_file.  As far as I
  754 can tell, unlink_file aborts in noexec mode and CVS_UNLINK does not.  I'm not
  755 sure it would be possible to remove even the use of temp files in noexec mode,
  756 but most unlinks should probably be using unlink_file and not CVS_UNLINK.
  758 198.  Remove references to deprecated cvs_temp_name function.
  760 199.  Add test for login & logout functionality, including support for
  761 backwards compatibility with old CVSROOTs.
  763 200.  Make a 'cvs add' without write access a non-fatal error so that
  764 the user's Entries file is updated and future 'cvs diffs' will work
  765 properly.  This should ease patch submission.
  767 201.  cvs_temp_file should be creating temporary files in a privately owned
  768 subdirectory of of temp due to security issues on some systems.
  770 202.  Enable rdiff to accept most diff options.  Make rdiff output look
  771 like diff's.  Make CVS diff garbage go to stderr and only standard diff
  772 output go to stdout.
  774 203.  Add val-tags additions to the tagging code.  Don't remove the
  775 update additions since val-tags could still be used as a cache when the
  776 repository was imported from elsewhere (the tags weren't applied with a
  777 version which wrote val-tags).
  779 204.  Add test case for compression.  A buf_shutdown error using compression
  780 wasn't caught by the test suite.
  782 205.  There are lots of cases where trailing slashes on directory names
  783 and other non-canonical paths confuse CVS.  Most of the cases that do
  784 work are handled on an ad-hoc basis.  We need to come up with a coherent
  785 strategy to address path canonicalization and apply it consistently.
  787 208.  Merge enhancements to the diff package back into the original GNU source.
  789 209.  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.
  797 210.  Explain to sanity.sh how to deal with paths with spaces and other odd
  798 characters in them.
  800 211.  Make sanity.sh run under the Win32 bash (cygwin) and maybe other Windex
  801 environments (e.g. DGSS or whatever the MSVC portability environemnt is called).
  803 212.  Autotestify (see autoconf source) sanity.sh.
  805 213.  Examine desirability of updating the regex library (regex.{c,h}) to the
  806 more recent versions that come with glibc and emacs.  It might be worth waiting
  807 for the emacs folks to get their act together and merge their changes into the
  808 glibc version.
  810 214.  Make options.h options configure script options instead.
  812 215.  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.
  818 218.  Fix "checkout -d ." in client/server mode.
  820 221.  Handle spaces in file/directory names.  (Most, if not all, of the
  821 internal infrastructure already handles them correctly, but most of the
  822 administrative file interfaces do not.)
  824 223.  Internationalization support.  This probably means using some kind
  825 of universal character set (ISO 10646?) internally and converting on
  826 input and output, which opens the locale can of worms.
  828 224.  Better timezone handling.  Many people would like to see times
  829 output in local time rather than UTC, but that's tricky since the
  830 conversion from internal form is currently done by the server who has no
  831 idea what the user's timezone even is, let alone the rules for
  832 converting to it.
  834    -  On the contrary, I think the MT server response should be easily adaptable
  835 for this purpose.  It is defined in cvsclient.texi as processed by the client
  836 if it knows how and printed to stdout otherwise.  A "time" tag or the like
  837 could be the usual CVS server UTC time string.  An old client could just print
  838 the time in UTC and a new client would know that it could convert the time to a
  839 local time string according to the localization settings before printing it.
  841 225.  Add support for --allow-root to server command.
  843 227.  'cvs release' should use the CVS/Root in the directory being released
  844 when such is specified rather than $CVSROOT.  In my work directory with no CVS
  845 dir, a release of subdirectories causes the released projects to be tested
  846 against my $CVSROOT environment variable, which often isn't correct but which
  847 can complete without generating error messages if the project also exists in
  848 the other CVSROOT.  This happens a lot with my copies of the ccvs project.
  850 228.  Consider adding -d to commit ala ci.
  852 229.  Improve the locking code to use a random delay with exponential
  853 backoff ala Ethernet and separate the notification interval from the
  854 wait interval.
  856 230.  Support for options like compression as part of the CVSROOT might be
  857 nice.  This should be fairly easy to implement now using the method options.
  859 234.  Noop commands should be logged in the history file.  Information can
  860 still be obtained with noop commands, for instance via `cvs -n up -p', and
  861 paranoid admins might appreciate this.  Similarly, perhaps diff operations
  862 should be logged.