i want to know whether cvs is a hostable solution? how good is cvs?
secondly i have cvs in lab with lease line can it handle multisite
development.
These are questions, not problems.
The answer to both is "yes, and it does a pretty good job."
Some sites that are using CVS in these ways
TCP is reasonbly good, but it is far from being 100% perfect, even on Ethernet.
SSH, with encryption and LZ compression, will detect *lots* more errors
in the transport!
Hunh? The only place I noticed hashing was in auth challenge.
I couldn't see anywhere that SSH puts an error-correction
Unfortunately, unset isn't portable. I just don't see this as being a
serious enough problem to worry about.
Oh c'mon. A portable fix for a confusing problem area is very simple:
env |sed -e 's/=.*'/=/' /tmp/clean$$
for V in PATH HOME TR AWK ... ; do
eval
Does anyone know how to enter a log message that expands multiple lines
using command line cvs commit -m?
It all depends on what shell you're using. try doing
cvs -m 'this is\
a long message' mod1 mod2...
___
Info-cvs mailing list
[EMAIL
Then cvs:// could mean connect to port 2401 and ask
what authentication methods are valid. The server would respond with a list and
the client would use whatever it thinks is the most secure to authenticate and set
up an encryption stream.
Oooh, no, you *DON'T* want to do that -- it's a
Is there any mechanism to extend cvsignore to match questionable files and
then use something like the "file" command to peek inside them to decide
whether to ignore them or not?
This seems doable. A quick hack would be to change ign_name to take a
new parameter:
int am_server
Change
find . -type dir -name 'CVS' -print | xargs rmdir
Except the CVS directories usually have files in them, causing rmdir to
fail. You probably want to replace "rmdir" with "rm -r". The paranoid
will hold their breath while executing that command. :) And then, also,
you probably want to remove
The goal would be to automatically commit updates to the generated
files whenever there are changes to their predecessor files.
I use the commitinfo file to force developers to maintain it all by
hand. For example, here's a line from a commitinfo in one of our
repositories:
^conf$
Again, I think my "get date from file" patch would help here. Do
-jbranch:date:.last
right?
My last word on the subject.
CVS requires everyone to be in your passwd file. So does SSH, no?
You say "what's so hard about that." I say that there are times when it
is difficult, impossible, or just plain not appropriate. If you cannot
imagine such scenarios, so be it.
/r$
No authentication should exist within CVS. Instead, CVS should be open to
pluggable authentication.
Since CVS relies on the underlying filesystem for its own authentication
and authorization decisions, this is is one of those things that is much
easier to say than to do. And even harder to
There is no
excuse for not using strong cryptographic security with CVS. There is
no excuse for building orthogonal protection mechanisms into any
application, and most especially not one that offers public network
services!
Except that doing it right is not the trivial job that you have
Seems to me the easiest fix is to add something like this to the
top of main()
{
char pidbuf[64];
sprintf(pidbuf, "CVSPID=%lu", (unsigned long)getpid());
putenv(pidbuf);
}
It seems to me that this also works for CVS server, but I'm
The following diff lets you use "file:FILENAME" where a datespec is
needed (e.g., -D flag) -- it gets the date from the file's modtime. It
also adds "date:" as a prefix in you case you already have a file named
11/01/00 :)
It seems to me this makes merging inout among branches easier and safer
And here's my fourth, this time with the attachment. :(
The following diff lets you use "file:FILENAME" where a datespec is
needed (e.g., -D flag) -- it gets the date from the file's modtime. It
also adds "date:" as a prefix in you case you already have a file named
11/01/00 :)
It seems
sorry for the spam.
How about changing Make_Date to be something like this?
char *
Make_Date (rawdate)
char *rawdate;
{
time_t unixtime;
! if (strncmp(rawdate, "file:", 5) == 0)) {
! struct stat sb;
! unixtime = stat(rawdate + 6, sb) 0 ? (time_t)-1 :
sb.st_mtime;
! }
! else
!
Is it possible to lock a branch, or somehow make it "read-only"
so that no further check-ins can be done on it? In perusing
of Cvedarquist and cvsbook.red-bean.com I can't find it.
Locking branches (actually "obsolete -lock") is a common
ClearCase practice that would be nice to have here.
If
http://www.egroups.com/message/info-cvs/16893?
That is a much better approach -- more general. I have a couple of nits:
the use of "?:" to determine the strings doesn't allow for growth :)
If the args were colon-separated key=value pairs, then I could do
Putting a CVS password in the environment makes it available with no
encryption at all to anyone who can run the ``ps'' command.
When accessing public repositories, there's no need to protect the
password. My note didn't make that clear enough, sorry.
What's
wrong with doing an
Can anyone give me a simple command that will remove all existing
files from a repository, but not remove the repository itself?
cd /path/to/your/repository
find . -type f -print | grep -v CVSROOT | xargs rm
Formatting is not stored anyway, so there is nothing to feel sorry about.
Being able to write ChangeLog in HTML woul be useful.
22 matches
Mail list logo
