head	1.2;
access;
symbols
	RELENG_8_4:1.1.1.9.0.18
	RELENG_9_1_0_RELEASE:1.1.1.9
	RELENG_9_1:1.1.1.9.0.16
	RELENG_9_1_BP:1.1.1.9
	RELENG_8_3_0_RELEASE:1.1.1.9
	RELENG_8_3:1.1.1.9.0.14
	RELENG_8_3_BP:1.1.1.9
	RELENG_9_0_0_RELEASE:1.1.1.9
	RELENG_9_0:1.1.1.9.0.12
	RELENG_9_0_BP:1.1.1.9
	RELENG_9:1.1.1.9.0.10
	RELENG_9_BP:1.1.1.9
	RELENG_7_4_0_RELEASE:1.1.1.8.18.1
	RELENG_8_2_0_RELEASE:1.1.1.9
	RELENG_7_4:1.1.1.8.18.1.0.8
	RELENG_7_4_BP:1.1.1.8.18.1
	RELENG_8_2:1.1.1.9.0.8
	RELENG_8_2_BP:1.1.1.9
	RELENG_8_1_0_RELEASE:1.1.1.9
	RELENG_8_1:1.1.1.9.0.6
	RELENG_8_1_BP:1.1.1.9
	RELENG_7_3_0_RELEASE:1.1.1.8.18.1
	RELENG_7_3:1.1.1.8.18.1.0.6
	RELENG_7_3_BP:1.1.1.8.18.1
	RELENG_8_0_0_RELEASE:1.1.1.9
	RELENG_8_0:1.1.1.9.0.4
	RELENG_8_0_BP:1.1.1.9
	RELENG_8:1.1.1.9.0.2
	RELENG_8_BP:1.1.1.9
	RELENG_7_2_0_RELEASE:1.1.1.8.18.1
	RELENG_7_2:1.1.1.8.18.1.0.4
	RELENG_7_2_BP:1.1.1.8.18.1
	RELENG_7_1_0_RELEASE:1.1.1.8.18.1
	RELENG_6_4_0_RELEASE:1.1.1.8
	RELENG_7_1:1.1.1.8.18.1.0.2
	RELENG_7_1_BP:1.1.1.8.18.1
	RELENG_6_4:1.1.1.8.0.24
	RELENG_6_4_BP:1.1.1.8
	v1_11_20080310:1.1.1.9
	RELENG_7_0_0_RELEASE:1.1.1.8
	RELENG_6_3_0_RELEASE:1.1.1.8
	v1_11_22:1.1.1.9
	PRE_1_11_22:1.1.1.8
	RELENG_7_0:1.1.1.8.0.22
	RELENG_7_0_BP:1.1.1.8
	RELENG_6_3:1.1.1.8.0.20
	RELENG_6_3_BP:1.1.1.8
	RELENG_7:1.1.1.8.0.18
	RELENG_7_BP:1.1.1.8
	RELENG_6_2_0_RELEASE:1.1.1.8
	RELENG_6_2:1.1.1.8.0.16
	RELENG_6_2_BP:1.1.1.8
	RELENG_5_5_0_RELEASE:1.1.1.8
	RELENG_5_5:1.1.1.8.0.14
	RELENG_5_5_BP:1.1.1.8
	RELENG_6_1_0_RELEASE:1.1.1.8
	RELENG_6_1:1.1.1.8.0.12
	RELENG_6_1_BP:1.1.1.8
	RELENG_6_0_0_RELEASE:1.1.1.8
	RELENG_6_0:1.1.1.8.0.10
	RELENG_6_0_BP:1.1.1.8
	RELENG_6:1.1.1.8.0.8
	RELENG_6_BP:1.1.1.8
	RELENG_5_4_0_RELEASE:1.1.1.8
	RELENG_5_4:1.1.1.8.0.6
	RELENG_5_4_BP:1.1.1.8
	RELENG_4_11_0_RELEASE:1.1.1.6.2.1
	RELENG_4_11:1.1.1.6.2.1.0.2
	RELENG_4_11_BP:1.1.1.6.2.1
	RELENG_5_3_0_RELEASE:1.1.1.8
	RELENG_5_3:1.1.1.8.0.4
	RELENG_5_3_BP:1.1.1.8
	RELENG_5:1.1.1.8.0.2
	RELENG_5_BP:1.1.1.8
	v1_11_17:1.1.1.8
	RELENG_4_10_0_RELEASE:1.1.1.6
	RELENG_4_10:1.1.1.6.0.24
	RELENG_4_10_BP:1.1.1.6
	v1_11_15:1.1.1.7
	RELENG_5_2_1_RELEASE:1.1.1.6
	RELENG_5_2_0_RELEASE:1.1.1.6
	RELENG_5_2:1.1.1.6.0.22
	RELENG_5_2_BP:1.1.1.6
	RELENG_4_9_0_RELEASE:1.1.1.6
	RELENG_4_9:1.1.1.6.0.20
	RELENG_4_9_BP:1.1.1.6
	RELENG_5_1_0_RELEASE:1.1.1.6
	RELENG_5_1:1.1.1.6.0.18
	RELENG_5_1_BP:1.1.1.6
	RELENG_4_8_0_RELEASE:1.1.1.6
	RELENG_4_8:1.1.1.6.0.16
	RELENG_4_8_BP:1.1.1.6
	v1_11_5:1.1.1.6
	RELENG_5_0_0_RELEASE:1.1.1.6
	RELENG_5_0:1.1.1.6.0.14
	RELENG_5_0_BP:1.1.1.6
	v1_11_2_1_20021201:1.1.1.6
	RELENG_4_7_0_RELEASE:1.1.1.6
	RELENG_4_7:1.1.1.6.0.12
	RELENG_4_7_BP:1.1.1.6
	v1_11_2:1.1.1.6
	RELENG_4_6_2_RELEASE:1.1.1.6
	RELENG_4_6_1_RELEASE:1.1.1.6
	RELENG_4_6_0_RELEASE:1.1.1.6
	RELENG_4_6:1.1.1.6.0.10
	RELENG_4_6_BP:1.1.1.6
	RELENG_4_5_0_RELEASE:1.1.1.6
	RELENG_4_5:1.1.1.6.0.8
	RELENG_4_5_BP:1.1.1.6
	RELENG_4_4_0_RELEASE:1.1.1.6
	RELENG_4_4:1.1.1.6.0.6
	RELENG_4_4_BP:1.1.1.6
	v1_11_1p1:1.1.1.6
	CVSHOME:1.1.1
	RELENG_4_3_0_RELEASE:1.1.1.6
	RELENG_4_3:1.1.1.6.0.4
	RELENG_4_3_BP:1.1.1.6
	RELENG_4_2_0_RELEASE:1.1.1.6
	v1_11:1.1.1.6
	RELENG_4_1_1_RELEASE:1.1.1.6
	PRE_SMPNG:1.1.1.6
	RELENG_4_1_0_RELEASE:1.1.1.6
	RELENG_3_5_0_RELEASE:1.1.1.4.2.2
	RELENG_4_0_0_RELEASE:1.1.1.6
	RELENG_4:1.1.1.6.0.2
	RELENG_4_BP:1.1.1.6
	RELENG_3_4_0_RELEASE:1.1.1.4.2.2
	v1_10_7:1.1.1.6
	RELENG_3_3_0_RELEASE:1.1.1.4.2.1
	RELENG_3_2_PAO:1.1.1.4.2.1.0.2
	RELENG_3_2_PAO_BP:1.1.1.4.2.1
	RELENG_3_2_0_RELEASE:1.1.1.4.2.1
	v1_10:1.1.1.5
	RELENG_3_1_0_RELEASE:1.1.1.4
	RELENG_3:1.1.1.4.0.2
	RELENG_3_BP:1.1.1.4
	RELENG_2_2_8_RELEASE:1.1.1.1.2.2
	RELENG_3_0_0_RELEASE:1.1.1.4
	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.4
	v1_9_24:1.1.1.4
	v1_9_23_19980123:1.1.1.4
	RELENG_2_2_5_RELEASE:1.1.1.1.2.1
	v1_9_10:1.1.1.3
	v1_9_9_970523:1.1.1.3
	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.04;	author peter;	state Exp;
branches;
next	1.1.1.3;

1.1.1.3
date	97.05.23.14.47.30;	author peter;	state Exp;
branches;
next	1.1.1.4;

1.1.1.4
date	98.01.26.03.07.45;	author peter;	state Exp;
branches
	1.1.1.4.2.1;
next	1.1.1.5;

1.1.1.5
date	99.03.18.09.21.21;	author peter;	state Exp;
branches;
next	1.1.1.6;

1.1.1.6
date	99.12.11.12.22.31;	author peter;	state Exp;
branches
	1.1.1.6.2.1;
next	1.1.1.7;

1.1.1.7
date	2004.04.15.01.01.55;	author peter;	state Exp;
branches;
next	1.1.1.8;

1.1.1.8
date	2004.06.10.19.05.37;	author peter;	state Exp;
branches
	1.1.1.8.18.1;
next	1.1.1.9;

1.1.1.9
date	2008.01.13.05.49.23;	author obrien;	state Exp;
branches
	1.1.1.9.18.1;
next	;

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

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

1.1.1.4.2.1
date	99.05.10.14.59.56;	author peter;	state Exp;
branches;
next	1.1.1.4.2.2;

1.1.1.4.2.2
date	99.12.13.20.56.19;	author peter;	state Exp;
branches;
next	;

1.1.1.6.2.1
date	2004.06.29.16.10.44;	author des;	state Exp;
branches;
next	;

1.1.1.8.18.1
date	2008.07.28.16.52.28;	author obrien;	state Exp;
branches;
next	;

1.1.1.9.18.1
date	2008.01.13.05.49.23;	author svnexp;	state dead;
branches;
next	1.1.1.9.18.2;

1.1.1.9.18.2
date	2013.03.28.13.00.39;	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
@To report bugs send mail to bug-cvs@@prep.ai.mit.edu, or run the "cvsbug"
program and fill out the template:

	$ cvsbug

The "cvsbug" program is installed in the same location as the "cvs"
program.  If your installation failed, you may need to run "cvsbug"
directly out of the "src" directory as "src/cvsbug.sh".  This is also
the procedure for submitting suggested changes to CVS--note that all
submitted changes may be distributed under the terms of the GNU Public
License, so if you don't like this, don't submit them.



* `cvs checkout -d nested/dir/path <module>' just doesn't work.  The
  simpler version -- `cvs checkout -d single-dir <module>' works,
  however.


* CVS leaves .#mumble files around when a conflict occurs.  (Note:
  this is intentional and is documented in doc/cvs.texinfo.  Of course
  whether it is a good idea is a separate question).


* pcl-cvs doesn't like it when you try to check in a file which isn't
  up-to-date.  The messages produced by the server perhaps don't match
  what pcl-cvs is looking for.


* From: Roland McGrath <roland@@gnu.ai.mit.edu>
  To: Cyclic CVS Hackers <info-cvs@@prep.ai.mit.edu>
  Subject: weird bug
  Date: Sat, 25 Mar 1995 16:41:41 -0500
  X-Windows: Even your dog won't like it.

  I just noticed some droppings on my disk from what must be a pretty weird
  bug in remote CVS.

  In my home directory on a repository machine I use, I find:

  drwxr-xr-x   4 roland   staff         512 Mar  7 14:08 cvs-serv28962
  drwxr-xr-x   4 roland   staff         512 Mar  7 14:11 cvs-serv28978
  drwxr-xr-x   4 roland   staff         512 Mar  7 15:13 cvs-serv29141

  OK, so these are leftover cruft from some cvs run that got aborted.
  Well, it should clean up after itself, but so what.

  The last one is pretty dull; the real weirdness is the contents of the
  first two directories.

  duality 77 # ls -RF cvs-serv28978/
  CVS/		cvs-serv28978/

  cvs-serv28978/CVS:
  Entries	    Repository

  cvs-serv28978/cvs-serv28978:
  arpa/

  cvs-serv28978/cvs-serv28978/arpa:
  CVS/		cvs-serv28978/

  cvs-serv28978/cvs-serv28978/arpa/CVS:
  Entries	    Repository

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978:
  assert/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert:
  CVS/		cvs-serv28978/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/CVS:
  Entries	    Repository

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978:
  bare/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare:
  CVS/		cvs-serv28978/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/CVS:
  Entries	    Repository

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978:
  conf/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf:
  CVS/		cvs-serv28978/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/CVS:
  Entries	    Repository

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978:
  crypt/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt:
  CVS/		cvs-serv28978/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/CVS:
  Entries	    Repository

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978:
  csu/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu:
  CVS/		cvs-serv28978/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/CVS:
  Entries	    Repository

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978:
  ctype/

  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype:
  CVS/		cvs-serv28978/

  [...]

  ls: cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype/cvs-serv28978/dirent/cvs-serv28978/elf/cvs-serv28978/gnu/cvs-serv28978/gnulib/cvs-serv28978/grp/cvs-serv28978/hurd/cvs-serv28978/hurd/hurd/cvs-serv28978/inet/cvs-serv28978/inet/arpa/cvs-serv28978/inet/netinet[...]/cvs-serv28978/posix/cvs-serv28978/posix/glob/cvs-serv28978/posix/gnu/cvs-serv28978/posix/sys/cvs-serv28978/protocols/cvs-serv28978/pwd/cvs-serv28978/resolv/cvs-serv28978/resolv/arpa/cvs-serv28978/resolv/sys/cvs-serv28978/resource/cvs-serv28978/resource/sys/cvs-serv28978/rpc/cvs-serv28978/setjmp/cvs-serv28978/signal/cvs-serv28978/signal/sys/cvs-serv28978/socket/cvs-serv28978/socket: File name too long
  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype/cvs-serv28978/dirent/cvs-serv28978/elf/cvs-serv28978/gnu/cvs-serv28978/gnulib/cvs-serv28978/grp/cvs-serv28978/hurd/cvs-serv28978/hurd/hurd/cvs-serv28978/inet/cvs-serv28978/inet/arpa/cvs-serv28978/inet/netinet[...]/cvs-serv28978/posix/glob/cvs-serv28978/posix/gnu/cvs-serv28978/posix/sys/cvs-serv28978/protocols/cvs-serv28978/pwd/cvs-serv28978/resolv/cvs-serv28978/resolv/arpa/cvs-serv28978/resolv/sys/cvs-serv28978/resource/cvs-serv28978/resource/sys/cvs-serv28978/rpc/cvs-serv28978/setjmp/cvs-serv28978/signal/cvs-serv28978/signal/sys/cvs-serv28978/socket/cvs-serv28978:


* From: billr@@mpd.tandem.com (Bill Robertson)
  Subject: Problem with rtag and the -D option
  Date: Fri, 17 Mar 1995 10:53:29 -0600 (CST)

  I have been trying to use the -D option to specify a date for tagging, but
  rtag does not recognize the -D option. It is documented to do so and I've
  tested the use of -D with cvs update and cvs diff and it works fine there.
  

*         We need some version numbers really badly.  Are there some
  (and Charles Hannum is just not including them in his reports), or do
  we simply have no reliable way to distinguish between the various
  versions of rCVS people on the list are running?
  
          Now that I think of it, version numbers present a problem when
  people can update their sources anytime and rebuild.  I think the
  solution is to increment a minor version number *every* time a bug is
  fixed, so we can identify uniquely what someone is running when they
  submit a report.  This implies recording the version increments in the
  ChangeLog; that way we can just look to see where a particular version
  lies in relation to the flow of changing code.
  
          Should we be doing same with Guppy?  I guess not -- it's only
  important when you have people who are updating directly from your
  development tree, which is the case with the remote-cvs folks.
  
          Thoughts?


* (Charles Hannum <mycroft@@ai.mit.edu>) has these bugs:

  I just tossed remote CVS at a fairly large source tree that I already
  had, and noticed a few problems:

  1) server.c assumes that /usr/tmp is a valid default for the place to
  store files uploaded from the client.  There are a number of systems
  that now use /var/tmp.  These should probably be detected by autoconf.

  2) The server deals rather ungracefully with the tmp directory
  becoming full.

  3) There's some oddness with relative paths in Repository files that
  causes the directory prefix to be added twice; e.g. if I have CVSROOT
  set to `machine:/this/dir', and I try to update in a directory whose
  Repository file says `src/bin', the server looks in
  `/this/dir/machine:/this/dir/src/bin'.

* From: "Charles M. Hannum" <mycroft@@ai.mit.edu>
  To: jimb@@duality.gnu.ai.mit.edu, roland@@duality.gnu.ai.mit.edu
  Subject: Serious flaw in remote CVS
  Date: Wed, 22 Feb 1995 20:54:36 -0500

  I just found a major flaw in the current implementation.  Because the
  sockets are not changed to non-blocking mode, write(2)s can hang.  In
  some cases, this happens on both sides at the same time, with the
  socket buffers full in both directions.  This causes a deadlock,
  because both processes are stuck in I/O wait and thus never drain
  their input queues.
  
  Until this is fixed, I can't use it.  I'll look at the problem myself
  at some point, but I don't know when.
  

  From: "Charles M. Hannum" <mycroft@@ai.mit.edu>
  To: info-cvs@@prep.ai.mit.edu
  Cc: jimb@@totoro.bio.indiana.edu
  Subject: Re: forwarded message from Charles M. Hannum
  Date: Wed, 22 Feb 1995 22:07:07 -0500
  
  FYI, this happened because the tmp directory on the server became
  full.  Somehow the server started interpreting the files the client
  was sending as commands, and started spewing tons of errors.
  Apparently the errors are sent with blocking I/O, or something, and
  thus allowed the deadlock to happen.


* From: "Charles M. Hannum" <mycroft@@ai.mit.edu>
  To: info-cvs@@prep.ai.mit.edu
  Subject: Regarding that relative path problem
  Date: Thu, 23 Feb 1995 02:41:51 -0500

  This is actually more serious.  If you have `bar.com:/foo' as your CVS
  root directory, then:

  1) When you check things out, the Repository files will contain
  `/foo/...' (i.e. without the machine name), which makes little sense.

  2) If you instead have a relative path, when the Repository file is
  read, `bar.com:/foo' is prepended.  This is sent to the server, but
  confuses it, because it's not expecting the machine name to be
  prepended.

  A slightly klugy fix would be to have the client prepend the machine
  name when writing a new Repository file, and strip it off before
  sending one to the server.  This would be backward-compatible with the
  current arrangement.


* From: "Charles M. Hannum" <mycroft@@ai.mit.edu>
  To: info-cvs@@prep.ai.mit.edu
  Subject: Still one more bug
  Date: Sat, 25 Feb 1995 17:01:15 -0500
  
  mycroft@@duality [1]; cd /usr/src/lib/libc
  mycroft@@duality [1]; cvs diff -c2 '-D1 day ago' -Dnow
  cvs server: Diffing .
  cvs server: Diffing DB
  cvs [server aborted]: could not chdir to DB: No such file or directory
  mycroft@@duality [1];
  
  `DB' is an old directory, which no longer has files in it, and is
  removed automatically when I use the `-P' option to checkout.
  
  This error doesn't occur when run locally.
  
  P.S.  Is anyone working on fixing these bugs?


* From: Roland McGrath <roland@@gnu.ai.mit.edu>
  To: Cyclic CVS Hackers <info-cvs@@prep.ai.mit.edu>
  Subject: bizarre failure mode
  Date: Tue, 7 Mar 95 14:17:28 -0500
  
  This is pretty weird:
  
  CVS_SERVER='TMPDIR=. /usr/local/bin/cvs' ../cvs-build/src/cvs update -q
  cvs [server aborted]: could not get working directory: Result too large
  [Exit 1]
  asylum 29 % grep 'Result too large' /usr/include/sys/errno.h 
  #define ERANGE          34              /* Result too large */
  
  Now, getcwd fails with ERANGE when the buffer is too small.  But I don't
  know why that would be the case; I don't think there are exceptionally long
  directory names involved.  It would be robust to notice ERANGE and use a
  bigger buffer.  But I suspect something weirder is going on.
  
  The repository in question in duality.gnu.ai.mit.edu:/gd4/gnu/cvsroot/libc.
  
  Send me a PGP-signed message if you want the password to use the machine
  where the problem showed up.
@


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 2
a2 2
See the README file for information on how to report bugs (and what
will happen to your bug reports if you do).
d4 1
a4 6
The following is a list of some of the known bugs.  It may or may not
be comprehensive.  We would dearly love for people to volunteer to
help us keep it up to date (for starters, if you notice any
inaccuracies, please let bug-cvs know as described in README).  There
are some other reported bugs in MINOR-BUGS; the difference, at least
in theory, is that those bugs are less serious.
d6 6
a12 46
* For platform-specific information (in some cases including known
bugs), see README.VMS, windows-NT/README, or os2/README.  There is no
similar file for the unix-like operating systems (not yet, at least).
This file also might contain some platform-specific bugs.


* Exporting binary files on non-unix clients with "cvs export" does
not work.  The workaround is to use "cvs checkout" instead.  If you
are thinking of fixing this, check out the comment "For cvs export,
assume it is a text file." in client.c.


* Wrappers do not work client/server, and there are a variety of other
bugs and annoyances with wrappers.


* Some people have reported seeing the message "dying gasps from %s
unexpected" (where %s is the name of your server) when using
client/server CVS.  One person reported that this had to do with using
pserver and trying to run a program not in the PATH (which is set up
by inetd, I think) from one of the *info scripts.  But noone has
carefully tracked this down (is it caused by something in the server
writing to stdout or stderr when it shouldn't?  But then wouldn't the
"dying gasps" message be preceded by "warning: unrecognized response
`%s' from cvs server"?).


* "make remotecheck" sometimes fails on test 187a3 with
    cvs server: in directory .:
    cvs [server aborted]: *PANIC* administration files missing
This does not happen every time.  (-kingdon, Nov 96, Red Hat linux 3.0.3).


* The -m option to "cvs add" does not work with client/server CVS.
CVS will accept the option, but it won't actually set the
file's description.


* cvs update walks into a user's work directory if there's a directory
  of the same name in the repository even if the user's directory
  doesn't yet have a CVS admin sub-directory.  This can greatly confuse
  users who try to add the same directory at nearly the same time.


* 'cvs admin' dumped core when files were missing from working directory
  (and from the repository)?
d20 3
a22 17
* The following bug was reported against CVS 1.9:

    Create a module named test with a file named test in it.

      cactus:sfavor> cvs get test
      cvs checkout: Updating test
      U test/test
      cactus:sfavor> cd test
      cactus:sfavor> cvs get test
      cvs checkout: cannot chdir to test: Not a directory
      cvs checkout: ignoring module test
      Exit 1
      cactus:sfavor> cvs update
      cvs update: Updating .
      rcs.c:2139: failed assertion `rev == NULL || isdigit (*rev)'
      Abort (core dumped)
      Exit 134
a29 30
* From: billr@@mpd.tandem.com (Bill Robertson)
  Subject: Problem with rtag and the -D option
  Date: Fri, 17 Mar 1995 10:53:29 -0600 (CST)

  I have been trying to use the -D option to specify a date for tagging, but
  rtag does not recognize the -D option. It is documented to do so and I've
  tested the use of -D with cvs update and cvs diff and it works fine there.

* Defining RELATIVE_REPOS is said to not work with client/server CVS.

* From: "Charles M. Hannum" <mycroft@@ai.mit.edu>
  To: info-cvs@@prep.ai.mit.edu
  Subject: Still one more bug
  Date: Sat, 25 Feb 1995 17:01:15 -0500
  
  mycroft@@duality [1]; cd /usr/src/lib/libc
  mycroft@@duality [1]; cvs diff -c2 '-D1 day ago' -Dnow
  cvs server: Diffing .
  cvs server: Diffing DB
  cvs [server aborted]: could not chdir to DB: No such file or directory
  mycroft@@duality [1];
  
  `DB' is an old directory, which no longer has files in it, and is
  removed automatically when I use the `-P' option to checkout.
  
  This error doesn't occur when run locally.
  
  P.S.  Is anyone working on fixing these bugs?


d121 119
@


1.1.1.1.2.2
log
@Merge cvs from HEAD.
@
text
@d1 2
a2 2
See the Cederqvist manual (cvs.texinfo) for information on how to
report bugs (and what will happen to your bug reports if you do).
d7 3
a9 3
inaccuracies, please let bug-cvs know as described in the Cederqvist
manual).  There are some other reported bugs in MINOR-BUGS; the
difference, at least in theory, is that those bugs are less serious.
d18 4
a21 4
* One cannot specify some files as binary in a "cvs import" using
CVSROOT/cvswrappers (for why, note that client_process_import_file has
no way of knowing about CVSROOT/cvswrappers which is off on the
server).
d24 1
a24 15
* I don't think that "cvs add" honors any of the -k wrappers, at least
not in client/server mode.  I would think it should.  Getting
CVSROOT/cvswrappers to work would presumably best be done by keeping a
copy of it in the CVS directory on the client, as has also been
discussed for CVS/Template, &c.  Getting a client-side .cvswrappers to
work is a separate issue.


* Need more work on the procedure for fixing it if a binary file is
accidentally added in text mode (sanity.sh test cases, better
documentation, probably update and/or admin -kb should update
the -k setting in CVS/Entries).


* Wrappers (-t/-f) do not work client/server, and there are a variety of other
d28 9
a36 15
* If your login name contains a space or various other characters
(particularly an issue on Windows), CVS will have trouble (it will
write invalid RCS files, probably).  The fix would be to have CVS
change such characters to underscores before writing them to the RCS
file.  Furthermore, the LOGNAME or USER environment variables usually
won't override the system login name, so this can be hard to work
around.


* If you specify the -w global option to client/server CVS, it only
overrides a CVSREAD environment variable set on the client, not a
CVSREAD variable which was set on the server (for example, in .bashrc
when the server was run via rsh).  The fix of course will be to
provide a "Option-read-write" request which sends -w, in addition to
"Global_option -r" which sends -r.
d58 5
@


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

Obtained from: cyclic.com
@
text
@d1 2
a2 2
See the README file for information on how to report bugs (and what
will happen to your bug reports if you do).
d4 1
a4 6
The following is a list of some of the known bugs.  It may or may not
be comprehensive.  We would dearly love for people to volunteer to
help us keep it up to date (for starters, if you notice any
inaccuracies, please let bug-cvs know as described in README).  There
are some other reported bugs in MINOR-BUGS; the difference, at least
in theory, is that those bugs are less serious.
d6 6
a12 36
* For platform-specific information (in some cases including known
bugs), see README.VMS, windows-NT/README, or os2/README.  There is no
similar file for the unix-like operating systems (not yet, at least).
This file also might contain some platform-specific bugs.


* Some people have reported seeing the message "dying gasps from %s
unexpected" (where %s is the name of your server) when using
client/server CVS.  One person reported that this had to do with using
pserver and trying to run a program not in the PATH (which is set up
by inetd, I think) from one of the *info scripts.  But noone has
carefully tracked this down (is it caused by something in the server
writing to stdout or stderr when it shouldn't?  But then wouldn't the
"dying gasps" message be preceded by "warning: unrecognized response
`%s' from cvs server"?).


* "make remotecheck" sometimes fails on test 187a3 with
    cvs server: in directory .:
    cvs [server aborted]: *PANIC* administration files missing
This does not happen every time.  (-kingdon, Nov 96, Red Hat linux 3.0.3).


* The -m option to "cvs add" does not work with client/server CVS.
CVS will accept the option, but it won't actually set the
file's description.


* cvs update walks into a user's work directory if there's a directory
  of the same name in the repository even if the user's directory
  doesn't yet have a CVS admin sub-directory.  This can greatly confuse
  users who try to add the same directory at nearly the same time.


* 'cvs admin' dumped core when files were missing from working directory
  (and from the repository)?
d20 3
a22 17
* The following bug was reported against CVS 1.9:

    Create a module named test with a file named test in it.

      cactus:sfavor> cvs get test
      cvs checkout: Updating test
      U test/test
      cactus:sfavor> cd test
      cactus:sfavor> cvs get test
      cvs checkout: cannot chdir to test: Not a directory
      cvs checkout: ignoring module test
      Exit 1
      cactus:sfavor> cvs update
      cvs update: Updating .
      rcs.c:2139: failed assertion `rev == NULL || isdigit (*rev)'
      Abort (core dumped)
      Exit 134
a29 30
* From: billr@@mpd.tandem.com (Bill Robertson)
  Subject: Problem with rtag and the -D option
  Date: Fri, 17 Mar 1995 10:53:29 -0600 (CST)

  I have been trying to use the -D option to specify a date for tagging, but
  rtag does not recognize the -D option. It is documented to do so and I've
  tested the use of -D with cvs update and cvs diff and it works fine there.

* Defining RELATIVE_REPOS is said to not work with client/server CVS.

* From: "Charles M. Hannum" <mycroft@@ai.mit.edu>
  To: info-cvs@@prep.ai.mit.edu
  Subject: Still one more bug
  Date: Sat, 25 Feb 1995 17:01:15 -0500
  
  mycroft@@duality [1]; cd /usr/src/lib/libc
  mycroft@@duality [1]; cvs diff -c2 '-D1 day ago' -Dnow
  cvs server: Diffing .
  cvs server: Diffing DB
  cvs [server aborted]: could not chdir to DB: No such file or directory
  mycroft@@duality [1];
  
  `DB' is an old directory, which no longer has files in it, and is
  removed automatically when I use the `-P' option to checkout.
  
  This error doesn't occur when run locally.
  
  P.S.  Is anyone working on fixing these bugs?


d121 119
@


1.1.1.3
log
@Import a slightly newer version of 1.9.9 (as at 970523) that has fixed a
few more memory leaks and cleaned up getopt usage.  These were done shortly
after the last one I imported.  Very little has changed other than that.
(except for some doc updates)

Obtained from: cyclic.com
@
text
@a17 10
* Exporting binary files on non-unix clients with "cvs export" does
not work.  The workaround is to use "cvs checkout" instead.  If you
are thinking of fixing this, check out the comment "For cvs export,
assume it is a text file." in client.c.


* Wrappers do not work client/server, and there are a variety of other
bugs and annoyances with wrappers.


@


1.1.1.4
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
@d1 2
a2 2
See the Cederqvist manual (cvs.texinfo) for information on how to
report bugs (and what will happen to your bug reports if you do).
d7 3
a9 3
inaccuracies, please let bug-cvs know as described in the Cederqvist
manual).  There are some other reported bugs in MINOR-BUGS; the
difference, at least in theory, is that those bugs are less serious.
d18 4
a21 4
* One cannot specify some files as binary in a "cvs import" using
CVSROOT/cvswrappers (for why, note that client_process_import_file has
no way of knowing about CVSROOT/cvswrappers which is off on the
server).
d24 1
a24 15
* I don't think that "cvs add" honors any of the -k wrappers, at least
not in client/server mode.  I would think it should.  Getting
CVSROOT/cvswrappers to work would presumably best be done by keeping a
copy of it in the CVS directory on the client, as has also been
discussed for CVS/Template, &c.  Getting a client-side .cvswrappers to
work is a separate issue.


* Need more work on the procedure for fixing it if a binary file is
accidentally added in text mode (sanity.sh test cases, better
documentation, probably update and/or admin -kb should update
the -k setting in CVS/Entries).


* Wrappers (-t/-f) do not work client/server, and there are a variety of other
d28 9
a36 15
* If your login name contains a space or various other characters
(particularly an issue on Windows), CVS will have trouble (it will
write invalid RCS files, probably).  The fix would be to have CVS
change such characters to underscores before writing them to the RCS
file.  Furthermore, the LOGNAME or USER environment variables usually
won't override the system login name, so this can be hard to work
around.


* If you specify the -w global option to client/server CVS, it only
overrides a CVSREAD environment variable set on the client, not a
CVSREAD variable which was set on the server (for example, in .bashrc
when the server was run via rsh).  The fix of course will be to
provide a "Option-read-write" request which sends -w, in addition to
"Global_option -r" which sends -r.
d58 5
@


1.1.1.4.2.1
log
@MFC: cvs-1.10 + FreeBSD mods preserved.
@
text
@d18 14
@


1.1.1.4.2.2
log
@MFC: cvs 1.10.7, as we run on freefall.

Approved by:	jkh
@
text
@d98 2
@


1.1.1.5
log
@Import cvs-1.10 onto vendor branch.  Merge to follow shortly.

Obtained from:	cyclic.com
@
text
@d18 14
@


1.1.1.6
log
@Import cvs-1.10.7.  There are a number of nasty bugs that have been fixed.

Obtained from:  cyclic.com
@
text
@d98 2
@


1.1.1.6.2.1
log
@MFC: upgrade to 1.11.17.

Approved by:	peter
@
text
@d18 10
d45 4
a48 13
* Symbolic links to files will not work with or without LockDir.  In the
repository, you should avoid using symbolic links to files since this issue
can cause data loss.  Symlinks are only a problem when writing files.  If your
repository does not allow any write access, symlinks are not a problem.


* Symbolic links to directories will not work with LockDir.  In the
repository, you should avoid using symbolic links to directories if
you intend to use LockDir as the correct directory will NOT be locked
by CVS during write.  Directory symlinks are not recommended, but should work
as long as LockDir is not being used.  Symlinks are only a problem when
writing files.  If your repository does not allow any write access, symlinks
are never a problem, whether or not LockDir is in use.
d62 36
d104 1
a104 1
  mycroft@@duality [1]; cvs diff -C2 '-D1 day ago' -Dnow
d118 17
a134 8
* CVS does not always seem to be waiting to the next filesystem timestamp
quanta after commits.  So far this has only shown up in testing under the BSDI
OS.  The symptoms are that ocassionally CVS will not notice that modified files
are modified, though the file must be modified within a short time after the
commit, probably milliseconds or seconds, for this symptom to be noticed.  One
suspected cause is that one of the calls to sleep_past() is being called with
an incorrect value, though this does not explain why symptoms have only been
noticed under BSDI.
d136 2
d139 2
a140 5
* Spaces in arguments to `cvs diff' are currently split on spaces and tabs
before being passed to diff.  This can often cause diff to abort since it can
no longer interpret its options string and if it can, coincidentally,
interpret its option string, then the problem may be output in unexpected
formats.
d142 2
d145 2
a146 2
* `release' of a project subdir does not remove the `subdir' entry from
  `./CVS/Entries'.
d148 2
d151 2
a152 3
* Most of the remote commands are encountering assertion failures when listing
  the toplevel of the repository (e.g. `cvs rlog .').  This appears to be
  related to the symlinked CVS root fix.
d154 2
d157 2
a158 1
* Status
d160 2
a161 3
                             /*-------.
                             | Stable |
                             `-------*/
d163 2
a164 3
                     /*-------------------------.
                     | Sane for full scale use. |
                     `-------------------------*/
d166 66
@


1.1.1.7
log
@Import cvs-1.11.15
@
text
@d18 10
a44 15
* Symbolic links to files will not work with or without LockDir.  In the
repository, you should avoid using symbolic links to files since this issue
can cause data loss.  Symlinks are only a problem when writing files.  If your
repository does not allow any write access, symlinks are not a problem.


* Symbolic links to directories will not work with LockDir.  In the
repository, you should avoid using symbolic links to directories if
you intend to use LockDir as the correct directory will NOT be locked
by CVS during write.  Directory symlinks are not recommended, but should work
as long as LockDir is not being used.  Symlinks are only a problem when
writing files.  If your repository does not allow any write access, symlinks
are never a problem, whether or not LockDir is in use.


d62 36
d104 1
a104 1
  mycroft@@duality [1]; cvs diff -C2 '-D1 day ago' -Dnow
a231 33

* CVS does not always seem to be waiting to the next filesystem timestamp
quanta after commits.  So far this has only shown up in testing under the BSDI
OS.  The symptoms are that ocassionally CVS will not notice that modified files
are modified, though the file must be modified within a short time after the
commit, probably milliseconds or seconds, for this symptom to be noticed.  One
suspected cause is that one of the calls to sleep_past() is being called with
an incorrect value, though this does not explain why symptoms have only been
noticed under BSDI.

* Spaces in arguments to `cvs diff' are currently split on spaces and tabs
before being passed to diff.  This can often cause diff to abort since it can
no longer interpret its options string and if it can, coincidentally,
interpret its option string, then the problem may be output in unexpected
formats.

* `release' of a project subdir does not remove the `subdir' entry from
  `./CVS/Entries'.

* The Windows Microsoft Visual C++ project files are out of date, but the
  project can still be built under Windows using `nmake'.  See the INSTALL
  file for more.

* Status

                             /*-------.
                             | Stable |
                             `-------*/

                     /*-------------------------.
                     | Sane for full scale use. |
                     `-------------------------*/

@


1.1.1.8
log
@Import cvs-1.11.17 onto vendor branch.
@
text
@d50 6
d87 115
a210 1

a216 1

d220 3
a222 5

* Most of the remote commands are encountering assertion failures when listing
  the toplevel of the repository (e.g. `cvs rlog .').  This appears to be
  related to the symlinked CVS root fix.

@


1.1.1.8.18.1
log
@SVN rev 180918 on 2008-07-28 16:52:28Z by obrien

MFC: CVS version 1.11.22.1 (almost 1.11.23).
@
text
@d91 16
@


1.1.1.9
log
@Import cvs-1.11.22 onto vendor branch.
@
text
@d91 16
@


1.1.1.9.18.1
log
@file BUGS was added on branch RELENG_8_4 on 2013-03-28 13:00:39 +0000
@
text
@d1 100
@


1.1.1.9.18.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 100
See the Cederqvist manual (cvs.texinfo) for information on how to
report bugs (and what will happen to your bug reports if you do).

The following is a list of some of the known bugs.  It may or may not
be comprehensive.  We would dearly love for people to volunteer to
help us keep it up to date (for starters, if you notice any
inaccuracies, please let bug-cvs know as described in the Cederqvist
manual).  There are some other reported bugs in MINOR-BUGS; the
difference, at least in theory, is that those bugs are less serious.


* For platform-specific information (in some cases including known
bugs), see README.VMS, windows-NT/README, or os2/README.  There is no
similar file for the unix-like operating systems (not yet, at least).
This file also might contain some platform-specific bugs.


* If your login name contains a space or various other characters
(particularly an issue on Windows), CVS will have trouble (it will
write invalid RCS files, probably).  The fix would be to have CVS
change such characters to underscores before writing them to the RCS
file.  Furthermore, the LOGNAME or USER environment variables usually
won't override the system login name, so this can be hard to work
around.


* If you specify the -w global option to client/server CVS, it only
overrides a CVSREAD environment variable set on the client, not a
CVSREAD variable which was set on the server (for example, in .bashrc
when the server was run via rsh).  The fix of course will be to
provide a "Option-read-write" request which sends -w, in addition to
"Global_option -r" which sends -r.


* Symbolic links to files will not work with or without LockDir.  In the
repository, you should avoid using symbolic links to files since this issue
can cause data loss.  Symlinks are only a problem when writing files.  If your
repository does not allow any write access, symlinks are not a problem.


* Symbolic links to directories will not work with LockDir.  In the
repository, you should avoid using symbolic links to directories if
you intend to use LockDir as the correct directory will NOT be locked
by CVS during write.  Directory symlinks are not recommended, but should work
as long as LockDir is not being used.  Symlinks are only a problem when
writing files.  If your repository does not allow any write access, symlinks
are never a problem, whether or not LockDir is in use.


* The -m option to "cvs add" does not work with client/server CVS.
CVS will accept the option, but it won't actually set the
file's description.


* cvs update walks into a user's work directory if there's a directory
  of the same name in the repository even if the user's directory
  doesn't yet have a CVS admin sub-directory.  This can greatly confuse
  users who try to add the same directory at nearly the same time.


* From: "Charles M. Hannum" <mycroft@@ai.mit.edu>
  To: info-cvs@@prep.ai.mit.edu
  Subject: Still one more bug
  Date: Sat, 25 Feb 1995 17:01:15 -0500
  
  mycroft@@duality [1]; cd /usr/src/lib/libc
  mycroft@@duality [1]; cvs diff -C2 '-D1 day ago' -Dnow
  cvs server: Diffing .
  cvs server: Diffing DB
  cvs [server aborted]: could not chdir to DB: No such file or directory
  mycroft@@duality [1];
  
  `DB' is an old directory, which no longer has files in it, and is
  removed automatically when I use the `-P' option to checkout.
  
  This error doesn't occur when run locally.
  
  P.S.  Is anyone working on fixing these bugs?


* CVS does not always seem to be waiting to the next filesystem timestamp
quanta after commits.  So far this has only shown up in testing under the BSDI
OS.  The symptoms are that ocassionally CVS will not notice that modified files
are modified, though the file must be modified within a short time after the
commit, probably milliseconds or seconds, for this symptom to be noticed.  One
suspected cause is that one of the calls to sleep_past() is being called with
an incorrect value, though this does not explain why symptoms have only been
noticed under BSDI.


* Status

                             /*-------.
                             | Stable |
                             `-------*/

                     /*-------------------------.
                     | Sane for full scale use. |
                     `-------------------------*/

@


