In a message dated 1/26/01 3:52:56 PM Eastern Standard Time,
[EMAIL PROTECTED] writes:
I have, but I think these occur when the client doesn't close down the
connection to the server properly. Sometimes I have pserver process
that hangs around for a couple of days, and I (or someone else)
In a message dated 1/24/01 8:46:41 PM Eastern Standard Time,
[EMAIL PROTECTED] writes:
At 4:48 PM -0800 1/24/01, Brian Behlendorf wrote:
On Wed, 24 Jan 2001, Russ Tremain wrote:
So we created a new device that was tuned for performance,
and mounted it on the /tmp used by the pserver.
I
One of my users complained she got this message whenever she checked out or updated in her module. I found that she had committed two of her binaries; one was 11Mb, the other was 7Mb. When I removed those files, the checkout/update worked.
I am running cvs 1.11 pserver with "-T /tmpcvs", where
I never had to support Windows developers before, but more of them are joining the CVS party lately. We have experienced case-sensitivity problems while importing releases of their code.
What happens is the first import will contain a file named "Foo.c". The next import, it might be called
I have a script that is invoked from taginfo to record what is tagged with "cvs tag" (since the history file only includes "cvs rtag" for some reason). Someone was tagging a HUGE module with "cvs rtag" and got the following:
cvs server: cannot exec /sccripts/cvstaglogger: Arg list too long
cvs
We're running happily on 1.10.8, but there were two bugs that I would be
willing to upgrade to 1.11 for if I knew they were fixed. Larry Jones
mentioned a memory leak in rcs.c that was "fixed in the development version"
before 1.11 came out. Also, there was some dumb bug limiting the length
I've set up a module where some of the subdirectories are writable by
everyone, and others are writable only by people in specific groups. It all
works well, but there are a couple of enhancements (which I'll gladly pay
for!) that I think would make the whole experience better.
When a user
I was trying to construct a build tree from modules checked out from 4
different repositories. I checked out the first to lay down the base, then
went into various subdirectories and did "cvs -d $repos2 co repos2_src" and
created my tree. What was cool was that I was able to go to the top of
In a message dated 9/29/00 6:08:26 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
I was a bit disappointed when I ran the initial checkout again like I did
when I first created the tree. It worked fine until it would enter a
directory from a
Greetings!
I usually get a lot of very helpful advice when I submit questions out here,
but this one went unnoticed. I realize, after reading it, that I wasn't very
clear, so I thought I'd try again.
I would like to be able to set up my CVS repository so that projects could be
owned by
Here's another one that seems to have fallen between the cracks. I was
wondering if it would be useful to other CVS users to be able to define a
.cvswrappers in a directory that applied to all files and subdirectories
under it. This would allow one project to say ".doc" was binary and
In a message dated 8/30/00 12:35:06 AM Eastern Daylight Time, [EMAIL PROTECTED]
writes:
Is there a way to restrict read/write access for a file based on a group
of userids?
not exactly -- access control in CVS is only possible (i.e. by default,
and in the obvious easy way) on a
One of the biggest complaints I get when I try to sell CVS to our client
development group is the lack of built-in binary detection. "cvswrappers"
provides some support for this, but we've found something awkward with it: An
extention considered "binary"
by a Mac may not be binary to a
I originally wrote:
I used to be able to commit like this:
cvs commit -m"foo changes" foo.c ../include/foo.h
After upgrading to CVS 1.10.8, I get this error:
protocol error: '..' has too many ..
This worked in 1.10.1. Is this a bug, or was it incorporated to fix
some
I used to be able to commit like this:
cvs commit -m"foo changes" foo.c ../include/foo.h
After upgrading to CVS 1.10.8, I get this error:
protocol error: '..' has too many ..
If I pass the full pathname of the file (e.g.,
"$HOME/cvs/foo/include/foo.h"), I get
absolute pathname
In a message dated 7/20/00 3:15:49 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
Perhaps the problem stems from "-F" meaning
"Force", thus allowing all sorts of questionable things to
be justified as part of "cvs tag -F" and overloading of "-F"
to move a normal tag, which is a
Greetings!
I've been tasked with improving the security of the access to our CVS
repository. [Cracker attacks will do this to managers... ;) ] We
currently use pserver, and have developed scripts which allow users to
request access to repositories via email to the owners, and then
Greetings!
I wanted to add a new subcommand to CVS for the fun of it. For now, let's
assume it's a "cvs ls" command to list the contents of a module/directory. I
was given the attached instructions by KJ Paradise at SourceGear. I followed
them exactly, and
added my command to the 2 lists
In a message dated 6/14/2000 10:27:10 AM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
I got everything working just nicely, but I ran into a bit of an
administration headache. I was hoping to be able to add users to
appropriate
groups in
Greetings!
I need WinCVS and "cvs checkout -c" to be able to list all of the modules in
our repository. The problem is, they both only list the contents of the
"CVSROOT/modules" file. (I assume WinCVS uses "co -c")
So, you say, simply add the modules to CVSROOT/modules!
One little
I notice that the old CVS command line client for windows isn't available for
1.10.8. I seem to have a 1.10.6 client, although I can't find it on
SourceGear's site anywhere so I'm not sure where I got it.
So:
1) The command line client isn't going away, right?
2) Can I get 1.10.8, or
Greetings!
Our developers will tag their code for builds under test, and when problems
are fixed, they will move the current tag until the product is shipped and
the tag is frozen. Occasionally, someone makes the mistake of moving the
branch tag instead of one of the branch's static tags.
22 matches
Mail list logo
