Low-priority bugs go here.  We don't have many yet -- everything is
high-priority at the moment. :-)


* From: Jeff Johnson <jbj@brewster.JBJ.ORG>
  To: cyclic-cvs@cyclic.com
  Subject: Named_Root assumes . on server
  Date: Wed, 17 May 1995 11:04:53 -0400 (EDT)
  
  Problem:
  	On server, Name_Root() attempts (aggressively) to set CVSADM_Root.
  	If ~/CVS/Root exists (wrto rsh login), then CVSADM_Root will be
  	initialized from that file. The sanity check between the root
  	repository and the invocation will fail if the two values are not
  	coincidentally the same.
  
  Workaround:
  	There's a zillion ways to fix this bugture/featurelet. My current
  	workaround is to remove ~/CVS/Root on the server. I shall attempt
  	a better fix as soon as I can determine what appears politically
  	correct. IMHO, the CVS/Root stuff (and getenv("CVSROOT") also) is
  	a bit fragile and tedious in an rcmd() driven CCVS environment.


* (Jeff Johnson <jbj@jbj.org>)
  I tried a "cvs status -v" and received the following:

  ? CVS
  ? programs/CVS
  ? tests/CVS
  cvs server: Examining .
  ===================================================================
  File: Install.dec            Status: Up-to-date
  ...
  
  I claim that CVS dirs should be ignored.


* I sometimes get this message:

  Could not look up address for your host.  Permission denied.
  cvs [update aborted]: premature end of file from server

  The client's response should be cleaned up.

* In the gb-grep module, update-ChangeLog (and therefore, I assume,
  rcs2log) truncates file names --- I get entries for things called
  ring/lenstring.h instead of lenstring/lenstring.h.

* On remote checkout, files don't have the right time/date stamps in
  the CVS/Entries files.  Doesn't look like the C/S protocol has any
  way to send this information along (according to cvsclient.texi).
  Perhaps we can spiff it up a bit by using the conflict field for the
  stamp on the checkout/update command.  Please note that this really
  doesn't do very much for us even if we get it done.

* Does the function that lists the available modules in the repository
  belong under the "checkout" function?  Perhaps it is more logically
  grouped with the "history" function or we should create a new "info"
  function?