head	1.2;
access;
symbols
	RELENG_8_4:1.1.1.3.0.80
	RELENG_9_1_0_RELEASE:1.1.1.3
	RELENG_9_1:1.1.1.3.0.78
	RELENG_9_1_BP:1.1.1.3
	RELENG_8_3_0_RELEASE:1.1.1.3
	RELENG_8_3:1.1.1.3.0.76
	RELENG_8_3_BP:1.1.1.3
	RELENG_9_0_0_RELEASE:1.1.1.3
	RELENG_9_0:1.1.1.3.0.74
	RELENG_9_0_BP:1.1.1.3
	RELENG_9:1.1.1.3.0.72
	RELENG_9_BP:1.1.1.3
	RELENG_7_4_0_RELEASE:1.1.1.3
	RELENG_8_2_0_RELEASE:1.1.1.3
	RELENG_7_4:1.1.1.3.0.70
	RELENG_7_4_BP:1.1.1.3
	RELENG_8_2:1.1.1.3.0.68
	RELENG_8_2_BP:1.1.1.3
	RELENG_8_1_0_RELEASE:1.1.1.3
	RELENG_8_1:1.1.1.3.0.66
	RELENG_8_1_BP:1.1.1.3
	RELENG_7_3_0_RELEASE:1.1.1.3
	RELENG_7_3:1.1.1.3.0.64
	RELENG_7_3_BP:1.1.1.3
	RELENG_8_0_0_RELEASE:1.1.1.3
	RELENG_8_0:1.1.1.3.0.62
	RELENG_8_0_BP:1.1.1.3
	RELENG_8:1.1.1.3.0.60
	RELENG_8_BP:1.1.1.3
	RELENG_7_2_0_RELEASE:1.1.1.3
	RELENG_7_2:1.1.1.3.0.58
	RELENG_7_2_BP:1.1.1.3
	RELENG_7_1_0_RELEASE:1.1.1.3
	RELENG_6_4_0_RELEASE:1.1.1.3
	RELENG_7_1:1.1.1.3.0.56
	RELENG_7_1_BP:1.1.1.3
	RELENG_6_4:1.1.1.3.0.54
	RELENG_6_4_BP:1.1.1.3
	v1_11_20080310:1.1.1.3
	RELENG_7_0_0_RELEASE:1.1.1.3
	RELENG_6_3_0_RELEASE:1.1.1.3
	v1_11_22:1.1.1.3
	PRE_1_11_22:1.1.1.3
	RELENG_7_0:1.1.1.3.0.52
	RELENG_7_0_BP:1.1.1.3
	RELENG_6_3:1.1.1.3.0.50
	RELENG_6_3_BP:1.1.1.3
	RELENG_7:1.1.1.3.0.48
	RELENG_7_BP:1.1.1.3
	RELENG_6_2_0_RELEASE:1.1.1.3
	RELENG_6_2:1.1.1.3.0.46
	RELENG_6_2_BP:1.1.1.3
	RELENG_5_5_0_RELEASE:1.1.1.3
	RELENG_5_5:1.1.1.3.0.44
	RELENG_5_5_BP:1.1.1.3
	RELENG_6_1_0_RELEASE:1.1.1.3
	RELENG_6_1:1.1.1.3.0.42
	RELENG_6_1_BP:1.1.1.3
	RELENG_6_0_0_RELEASE:1.1.1.3
	RELENG_6_0:1.1.1.3.0.40
	RELENG_6_0_BP:1.1.1.3
	RELENG_6:1.1.1.3.0.38
	RELENG_6_BP:1.1.1.3
	RELENG_5_4_0_RELEASE:1.1.1.3
	RELENG_5_4:1.1.1.3.0.36
	RELENG_5_4_BP:1.1.1.3
	RELENG_4_11_0_RELEASE:1.1.1.3
	RELENG_4_11:1.1.1.3.0.34
	RELENG_4_11_BP:1.1.1.3
	RELENG_5_3_0_RELEASE:1.1.1.3
	RELENG_5_3:1.1.1.3.0.32
	RELENG_5_3_BP:1.1.1.3
	RELENG_5:1.1.1.3.0.30
	RELENG_5_BP:1.1.1.3
	v1_11_17:1.1.1.3
	RELENG_4_10_0_RELEASE:1.1.1.3
	RELENG_4_10:1.1.1.3.0.28
	RELENG_4_10_BP:1.1.1.3
	v1_11_15:1.1.1.3
	RELENG_5_2_1_RELEASE:1.1.1.3
	RELENG_5_2_0_RELEASE:1.1.1.3
	RELENG_5_2:1.1.1.3.0.26
	RELENG_5_2_BP:1.1.1.3
	RELENG_4_9_0_RELEASE:1.1.1.3
	RELENG_4_9:1.1.1.3.0.24
	RELENG_4_9_BP:1.1.1.3
	RELENG_5_1_0_RELEASE:1.1.1.3
	RELENG_5_1:1.1.1.3.0.22
	RELENG_5_1_BP:1.1.1.3
	RELENG_4_8_0_RELEASE:1.1.1.3
	RELENG_4_8:1.1.1.3.0.20
	RELENG_4_8_BP:1.1.1.3
	v1_11_5:1.1.1.3
	RELENG_5_0_0_RELEASE:1.1.1.3
	RELENG_5_0:1.1.1.3.0.18
	RELENG_5_0_BP:1.1.1.3
	v1_11_2_1_20021201:1.1.1.3
	RELENG_4_7_0_RELEASE:1.1.1.3
	RELENG_4_7:1.1.1.3.0.16
	RELENG_4_7_BP:1.1.1.3
	v1_11_2:1.1.1.3
	RELENG_4_6_2_RELEASE:1.1.1.3
	RELENG_4_6_1_RELEASE:1.1.1.3
	RELENG_4_6_0_RELEASE:1.1.1.3
	RELENG_4_6:1.1.1.3.0.14
	RELENG_4_6_BP:1.1.1.3
	RELENG_4_5_0_RELEASE:1.1.1.3
	RELENG_4_5:1.1.1.3.0.12
	RELENG_4_5_BP:1.1.1.3
	RELENG_4_4_0_RELEASE:1.1.1.3
	RELENG_4_4:1.1.1.3.0.10
	RELENG_4_4_BP:1.1.1.3
	v1_11_1p1:1.1.1.3
	CVSHOME:1.1.1
	RELENG_4_3_0_RELEASE:1.1.1.3
	RELENG_4_3:1.1.1.3.0.8
	RELENG_4_3_BP:1.1.1.3
	RELENG_4_2_0_RELEASE:1.1.1.3
	v1_11:1.1.1.3
	RELENG_4_1_1_RELEASE:1.1.1.3
	PRE_SMPNG:1.1.1.3
	RELENG_4_1_0_RELEASE:1.1.1.3
	RELENG_3_5_0_RELEASE:1.1.1.3
	RELENG_4_0_0_RELEASE:1.1.1.3
	RELENG_4:1.1.1.3.0.6
	RELENG_4_BP:1.1.1.3
	RELENG_3_4_0_RELEASE:1.1.1.3
	v1_10_7:1.1.1.3
	RELENG_3_3_0_RELEASE:1.1.1.3
	RELENG_3_2_PAO:1.1.1.3.0.4
	RELENG_3_2_PAO_BP:1.1.1.3
	RELENG_3_2_0_RELEASE:1.1.1.3
	v1_10:1.1.1.3
	RELENG_3_1_0_RELEASE:1.1.1.3
	RELENG_3:1.1.1.3.0.2
	RELENG_3_BP:1.1.1.3
	RELENG_2_2_8_RELEASE:1.1.1.1.2.2
	RELENG_3_0_0_RELEASE:1.1.1.3
	RELENG_2_2_7_RELEASE:1.1.1.1.2.2
	RELENG_2_2_6_RELEASE:1.1.1.1.2.1
	v1_9_26:1.1.1.3
	v1_9_24:1.1.1.3
	v1_9_23_19980123:1.1.1.3
	RELENG_2_2_5_RELEASE:1.1.1.1.2.1
	v1_9_10:1.1.1.2
	v1_9_9_970523:1.1.1.2
	RELENG_2_2_2_RELEASE:1.1.1.1
	v1_9_9_970515:1.1.1.2
	RELENG_2_2_1_RELEASE:1.1.1.1
	RELENG_2_2_0_RELEASE:1.1.1.1
	RELENG_2_2:1.1.1.1.0.2
	RELENG_2_2_BP:1.1.1.1
	v1_8_1:1.1.1.1
	CYCLIC:1.1.1;
locks; strict;
comment	@# @;


1.2
date	2013.06.16.00.38.19;	author svnexp;	state dead;
branches;
next	1.1;

1.1
date	96.08.20.23.45.57;	author peter;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	96.08.20.23.45.57;	author peter;	state Exp;
branches
	1.1.1.1.2.1;
next	1.1.1.2;

1.1.1.2
date	97.05.15.22.45.02;	author peter;	state Exp;
branches;
next	1.1.1.3;

1.1.1.3
date	98.01.26.03.07.51;	author peter;	state Exp;
branches
	1.1.1.3.80.1;
next	;

1.1.1.1.2.1
date	97.06.28.03.21.23;	author peter;	state Exp;
branches;
next	1.1.1.1.2.2;

1.1.1.1.2.2
date	98.04.05.03.27.19;	author peter;	state Exp;
branches;
next	;

1.1.1.3.80.1
date	98.01.26.03.07.51;	author svnexp;	state dead;
branches;
next	1.1.1.3.80.2;

1.1.1.3.80.2
date	2013.03.28.13.00.40;	author svnexp;	state Exp;
branches;
next	;


desc
@@


1.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/251794
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@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?
@


1.1
log
@Initial revision
@
text
@@


1.1.1.1
log
@Import of slightly trimmed cvs-1.8 distribution.  Generated files
and non-unix code has been left out.
@
text
@@


1.1.1.1.2.1
log
@Update 2.2 to cvs-1.9.10 from -current (fixes a security problem with
pserver mode)
@
text
@d1 23
a23 34
Low-priority bugs go here.  Actually, most every documented bug is
"low-priority"--in the sense that if it is documented it means noone
has gotten around to fixing it.


* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the
  '-ko', at least in client/server mode.  A simple work around is to
  temporarily change the db file with "cvs admin -ko file", then switch
  it back to the original modes after the checkout (probably '-kkv').

* "cvs status" has a difference in its output between local and
  client/server mode.  Namely there's a tab character followed by a
  ctime(3)-style date string at the end of the "Working revision:"
  field.

* commands which don't work in a local working directory should probably
  ignore any CVS/Root values and revert to using CVSROOT alone.  The
  current use of CVS/Root can be very confusing if you forget you're in
  a working directory for a remote module -- something that's very easy
  to do since CVS hides the client operation very well, esp. for
  commands which fail for this reason.  The only clue might be the word
  "server" in a message such as this:
	cvs server: cannot find module `patch' - ignored

* cvs init may gave a strange error at times:
	ttyp4:<woods@@clapton> $ cvs -d /local/src-CVS init
	cvs [init aborted]: cannot open CVS/Root: No such file or directory
  but it seemed to work just the same....  Note that at the time CVSROOT
  was set to point to a CVS server using the ":server:" option.

* If a ~/CVS/Root file exists on the server and you are using rsh to
connect to the server, CVS may loose its mind (this was reported in
May 1995 and I suspect the symptoms have changed, but I have no
particular reason to think the bug is fixed -kingdon, Sep 96).
d37 12
a48 2
  (I don't *think* this always happens; is "-I !" getting picked up somewhere
  something like that? -kingdon, Sep 96)
@


1.1.1.1.2.2
log
@Merge cvs from HEAD.
@
text
@d48 2
a49 2
  (This reportedly happens if "cvs add CVS" (or "cvs add *")
  is followed by "cvs status", in client/server mode - CVS 1.9).
@


1.1.1.2
log
@Import of cvs-1.9.9-970515 onto vendor branch.

Obtained from: cyclic.com
@
text
@d1 23
a23 34
Low-priority bugs go here.  Actually, most every documented bug is
"low-priority"--in the sense that if it is documented it means noone
has gotten around to fixing it.


* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the
  '-ko', at least in client/server mode.  A simple work around is to
  temporarily change the db file with "cvs admin -ko file", then switch
  it back to the original modes after the checkout (probably '-kkv').

* "cvs status" has a difference in its output between local and
  client/server mode.  Namely there's a tab character followed by a
  ctime(3)-style date string at the end of the "Working revision:"
  field.

* commands which don't work in a local working directory should probably
  ignore any CVS/Root values and revert to using CVSROOT alone.  The
  current use of CVS/Root can be very confusing if you forget you're in
  a working directory for a remote module -- something that's very easy
  to do since CVS hides the client operation very well, esp. for
  commands which fail for this reason.  The only clue might be the word
  "server" in a message such as this:
	cvs server: cannot find module `patch' - ignored

* cvs init may gave a strange error at times:
	ttyp4:<woods@@clapton> $ cvs -d /local/src-CVS init
	cvs [init aborted]: cannot open CVS/Root: No such file or directory
  but it seemed to work just the same....  Note that at the time CVSROOT
  was set to point to a CVS server using the ":server:" option.

* If a ~/CVS/Root file exists on the server and you are using rsh to
connect to the server, CVS may loose its mind (this was reported in
May 1995 and I suspect the symptoms have changed, but I have no
particular reason to think the bug is fixed -kingdon, Sep 96).
d37 12
a48 2
  (I don't *think* this always happens; is "-I !" getting picked up somewhere
  something like that? -kingdon, Sep 96)
@


1.1.1.3
log
@Import cvs-1.9.23 as at 19980123.  There are a number of really nice
things fixed in here, including the '-ko' vs. -A problem with
remote cvs which caused all files with -ko to be resent each time
(which is damn painful over a modem, I can tell you).  It also found a
heap of stray empty directories that should have been pruned with the -P
flag to cvs update but were not for some reason.

It also has the fully integrated rcs and diff, so no more fork/exec
overheads for rcs,ci,patch,diff,etc.  This means that it parses the control
data in the rcs files only once rather than twice or more.

If the 'cvs diff' vs. Index thing is going to be fixed for future patch
compatability, this is the place to do it.
@
text
@d48 2
a49 2
  (This reportedly happens if "cvs add CVS" (or "cvs add *")
  is followed by "cvs status", in client/server mode - CVS 1.9).
@


1.1.1.3.80.1
log
@file MINOR-BUGS was added on branch RELENG_8_4 on 2013-03-28 13:00:40 +0000
@
text
@d1 61
@


1.1.1.3.80.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 61
Low-priority bugs go here.  Actually, most every documented bug is
"low-priority"--in the sense that if it is documented it means noone
has gotten around to fixing it.


* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the
  '-ko', at least in client/server mode.  A simple work around is to
  temporarily change the db file with "cvs admin -ko file", then switch
  it back to the original modes after the checkout (probably '-kkv').

* "cvs status" has a difference in its output between local and
  client/server mode.  Namely there's a tab character followed by a
  ctime(3)-style date string at the end of the "Working revision:"
  field.

* commands which don't work in a local working directory should probably
  ignore any CVS/Root values and revert to using CVSROOT alone.  The
  current use of CVS/Root can be very confusing if you forget you're in
  a working directory for a remote module -- something that's very easy
  to do since CVS hides the client operation very well, esp. for
  commands which fail for this reason.  The only clue might be the word
  "server" in a message such as this:
	cvs server: cannot find module `patch' - ignored

* cvs init may gave a strange error at times:
	ttyp4:<woods@@clapton> $ cvs -d /local/src-CVS init
	cvs [init aborted]: cannot open CVS/Root: No such file or directory
  but it seemed to work just the same....  Note that at the time CVSROOT
  was set to point to a CVS server using the ":server:" option.

* If a ~/CVS/Root file exists on the server and you are using rsh to
connect to the server, CVS may loose its mind (this was reported in
May 1995 and I suspect the symptoms have changed, but I have no
particular reason to think the bug is fixed -kingdon, Sep 96).

* (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.
  (This reportedly happens if "cvs add CVS" (or "cvs add *")
  is followed by "cvs status", in client/server mode - CVS 1.9).

* 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?
@


