Hello!
Now everybody can run "sanity.sh -r" - my patch removes any dependency on
the system-wide rsh.
Instead, sanity.sh creates a file named "trsh" - trivial remote shell that
simply ignores the hostname and (if given) the username.
It is very important that many people run sanity.sh now when
[ On Tuesday, June 20, 2000 at 10:41:16 (+0100), J. Cone wrote: ]
> Subject: RE: ".trunk" patch refinement
>
> If they've migrated from sccs, this will have been done for them :-)
Yeah, no thanks to the broken use of sccs2rcs. Unfortunately nobody
ever wrote an "sccs2cvs" that would properly tra
Mr. Jones, thanks for the quick response.
> Someone else [[EMAIL PROTECTED]] reported this same bug just
> last week and there was some discussion about what to do -- the
> bug is, as you surmise, that update fails to detect a conflict
> when a locally-modified file has been removed by someone e
Kenneth Duda writes:
>
> I believe I have found a bug in CVS-1.10.8 (RCS version 5.7).
Someone else reported this same bug just last week and there was some
discussion about what to do -- the bug is, as you surmise, that update
fails to detect a conflict when a locally-modified file has been rem
Hello,
I believe I have found a bug in CVS-1.10.8 (RCS version 5.7).
Suppose two users have a file checked out at revision 1.1.
Suppose user A cvs removes the file and commits, which moves the
file into the attic and creates a dead revision 1.2 which is
otherwise identical to 1.1. Then user B
Program:cvs
Version:1.10
Host: all
Area: client
Synopsis: cvs co fails with &module inclusion
Description:
"cvs checkout" fails with the following error messages:
benz:/tmp(3)> cvs co odstb_all
cvs server: Updating odstb
cvs server: Updating odstb/
If they've migrated from sccs, this will have been done for them :-)
At 05:01 PM 6/19/00 -0400, Greg A. Woods wrote:
>However people should *not* ever be doing such silly things -- there are
>more corner cases than just this one whre they can get into trouble!
