Re: problems with cvs!!
> 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 include www.apache.org www.sourceforge.net www.openavenue.com www.openssl.org etc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: single-bit errors
> 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 code on top of the TCP stream. The CRC could let corruption happen, but I betcha all sorts of things break. Everyone assumes TCP doesn't mess up the bytes in-transit. /r$ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
> 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 "save$V=$V" done . /tmp/clean$$ for V in PATH HOME TR AWK ... do eval "$V=save$V ; export $V" done Save the env vars sanity cares about, then by definition you don't care what values the other env vars are. :) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Multiple-line log message
> 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 PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: login failure on WindowsNT
> 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 classic "man in the middle" attack. I can sit between you and the server and force you to downgrade to a lower security level. Early SSL had this problem. Designing security protocols is hard. Recommend we stick to one hard problem (source control) here. /r$ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Bug in client.c?
> > there must be something wrong with your checkout. CVSroot_port is > > declared on line 385 of src/cvs.h Right, but is it defined anywhere -- i.e., in some C file w/o the "extern" ? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: What is Cederqvist?
> Well this old timer really thinks it very very very bad form to refer to > something like this by the disembodied name of its creator What, you've never heard "according to Hoyle" or "as it says in Webster's" Lawyer's will also talk about "Black's" (law dictionary) and Chemists the "CRC", etc. Not only is it a common use, it's a sign of respect that one person has (originally) authored the definitive reference. /r$
Re: Generated files.
> 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 change if (!ign_name (arg)) in server.c to be if (!ign_name (arg, 1)) and change the other calls to ", 0" Then change ign_name() to look at the first character of the pattern, see if it's a "|" ... The problem is that ign_add splits on spaces. So perhaps the |xxx syntax could be used to indicate a named test (like commitinfo) in a new CVSROOT file?
Re: A truely ugly hack...
> 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$ ${CVSROOT}/CVSROOT/run-autoconf.pl
Attached is the run-autoconf perl script. I can think of a more general
approach (use an assoc array that is eval'd into the perl script to
maintain dependencies and add them to the "must be found" list) which I
could throw together if there's interest.
/r$
run-autoconf.pl
Re: remove CVS dirs under the working dir?
> 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 anything like .cvsignore files (if you have em), etc. etc. All in all, "cvs export" is probably the better way to go. As others have pointed out, the right way to go is to use only one source control system. /r$
Re: merging main trunk to branch?
Again, I think my "get date from file" patch would help here. Do -jbranch:date:.last right?
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
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$
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVS chroot)
> 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 repeatedly said it is. CVS requires the local operating system to do all its authorization checks for it. That means that you have to map all remote users into a local identity. Or, you have to trust the server to (completely) mediate access the objects that it is serving up. But, there are times when this is not feasible (or even possible), and people do things like hack cvspasswd files, "triggers" in info scripts, etc. > There are 20-30 years of history and science behind the > development of safer ways to network and now with the likes of SSH we > can deploy these techniques with *far* less cost than any *single* risk > we would face by not deploying them. As long as "all the world's a vax." Or, at least, in my passwd database... /r$
Re: cvs-nserver and latest CVS advisory (Was: patch to make CVSchroot)
> 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 get right. /r$
Re: patch to make CVS chroot
> I've patched CVS 1.10.8 so that it supports a new command line option: > > cvs --chroot /some/chroot/root/ Wouldn't it be easier to just run chroot /some/chroot/root cvs out of [x]inetd? Doing this also avoids the concern about "did I do the chroot soon enough" which could happen if/when other special arg processing is done. I know you can say the same thing about my getpid/putenv patch. I'd consider that slightly different since that also works for non-pserver. But I do think it's an issue for us to consider: when to patch main() and when to write wrappers? /r$
Re: CVS pids and the pids of its kids
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 not sure.
/r$
Re: Using files for -D timestamps
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 to me this makes merging in&out among branches easier and safer
> (more atomic) -- you don't have to worry about someone coming in and
> updating a file between your merges. Right?
>
> Here's how I'd use it to merge out from the main to my branch. Make
> sense?
> update -jHEAD:file:.last -jHEAD:file:now >.now && mv .now .last
>
> /r$
>
> PS: Apologies for the test-spam the other day; this is my third attempt
> to get this note out to the list.
Index: src/main.c
===
RCS file: /home2/cvsroot/ccvs/src/main.c,v
retrieving revision 1.152
diff -c -r1.152 main.c
*** src/main.c 2000/07/10 19:34:21 1.152
--- src/main.c 2000/07/11 13:26:31
***
*** 1069,1075
{
time_t unixtime;
! unixtime = get_date (rawdate, (struct timeb *) NULL);
if (unixtime == (time_t) - 1)
error (1, 0, "Can't parse date/time: %s", rawdate);
return date_from_time_t (unixtime);
--- 1069,1086
{
time_t unixtime;
! if (strncmp(rawdate, "file:", 5) == 0)
! {
! struct stat sb;
! rawdate += 5;
! unixtime = stat(rawdate, &sb) < 0 ? (time_t)-1 : sb.st_mtime;
! }
! else
! {
! if (strncmp(rawdate, "date:", 5) == 0)
! rawdate += 5;
! unixtime = get_date (rawdate, (struct timeb *) NULL);
! }
if (unixtime == (time_t) - 1)
error (1, 0, "Can't parse date/time: %s", rawdate);
return date_from_time_t (unixtime);
Using files for -D timestamps
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 in&out among branches easier and safer (more atomic) -- you don't have to worry about someone coming in and updating a file between your merges. Right? Here's how I'd use it to merge out from the main to my branch. Make sense? update -jHEAD:file:.last -jHEAD:file:now >.now && mv .now .last /r$ PS: Apologies for the test-spam the other day; this is my third attempt to get this note out to the list.
testing sorry
sorry for the spam.
-D/path/to/file
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
! unixtime = get_date (rawdate, (struct timeb *) NULL);
if (unixtime == (time_t) - 1)
error (1, 0, "Can't parse date/time: %s", rawdate);
return date_from_time_t (unixtime);
}
I think this would make merging in/out among branches easier
to handle. I could use fewer tags and instead do something like
touch .now
update -jHEAD:file:.last -jHEAD:file:.now && \
mv .new .last
(I think I have it right.)
I think this is also likely to be more atomic.
Comments?
/r$
-D/path/to/file
How about changing Make_Date to be like this?
char *
Make_Date (rawdate)
char *rawdate;
{
time_t unixtime;
! if (*rawdate == '/') {
! struct stat sb;
! unixtime = stat(rawdate, &sb) < 0 ? 0 : sb.st_mtime;
! }
! else
! unixtime = get_date (rawdate, (struct timeb *) NULL);
if (unixtime == (time_t) - 1)
error (1, 0, "Can't parse date/time: %s", rawdate);
return date_from_time_t (unixtime);
}
Then you could use the filesystem to keep timestamps...
Re: "Locking" branches
> 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 eval `echo $1 | tr : ' '` The second nit allows for expansion, and also means xT_ADD could become WHERE=BRANCH:OP=ADDTAG and C_ADD would be OP=ADDFILE or some such mixture. (Clearly the opcodes are disjoint to allow a single script to handle both things.) What's the likelihood of that functionality appearing? /r$
"Locking" branches
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 not, this seems to fit into the CVS philosophy: 1. Define a new special tag (cf HEAD) called LOCKED. 2. This tag is always sticky. 3. On checkout, if the version is tagged LOCKED, then (try to) remove write permission. 4. On checkin, fail if the version was tagged LOCKED. Comments? /r$
Re: automating login (passwords)
> As of CVS 1.10.8 public repositories don't need passwords at all, which
> avoids the problem.
Only when the world's repositories (or at least sourceforge :) upgrade.
> (If you can
> run a script as the user you should be able to su, no?)
What, you don't use setuid wrappers and run shell scripts? :)
> The transliteration is like putting a letter in an envelope rather than
> sending a postcard -- it won't stop anyone who really wants to read it
> from reading it, but it will keep the idly curious from reading it.
I don't think analogy quite works, since I don't need to read it to use it,
I can just copy it into my own .cvspass file
export CVSPASSFILE=/tmp/p$$
cat /home/*/.cvspass >CVSPASSFILE
I hope I'm not belaboring a point, but the illusion ("ooh, they're
encrypted")
really gives a false sense of security. Particularly for repositories, I
believe. They're either public (to the Internet, or corporate behind a
firewall)
or they're very very private. I don't think "the idly curious" really enter
into the situation.
> > How about
> > adding something like this near the top of descramble()
> > if (str[0] == 'B')
> > return xstrdup (str+1);
> > Perhaps P for plaintext? I would then change scramble to output the B method.
>
> I wouldn't have any objections to something like that.
Cool. So how does that go about getting done?
/r$
Re: automating login (passwords)
> 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 interactive ``cvs login'' as the user the script is > going to run as so the password is stored in ~/.cvspass? I'd rather not muck with the (sic) encryption. I know I can login once, and cut-and-paste the entry into the script-runner's passfile, but that's more than a little bit hokey. Come to think of it, isn't it time to bite the bullet and just get rid of the password transliteration? It only provides a fall sense of security; once you can read the .cvspass file, you can get the passwords. How about adding something like this near the top of descramble() if (str[0] == 'B') return xstrdup (str+1); Perhaps P for plaintext? I would then change scramble to output the B method. I mean this seriously. /r$
automating login (passwords)
This diff allows CVS login to get the password from an environment variable;
it's very useful when using automatic update scripts (e.g., run out of
cron). Perhaps CVSPASSFILE is a better way to go, but I didn't want to deal
with the the (de)scrambling. And this avoids any issues if/when someone adds
real encryption to the passfile.
A couple of improvements do come to mind:
(1) Warn if CVSPASSWORD is set and isatty(fileno(stdin))
i.e., warn if being used interactively. I didn't do this because
I didn't want to address the portability of that test.
(2) Allow the other commands to transparently login and logout.
So that something like this would work (/bin/sh syntax)
CVSROOT="" CVSPASSWORD="guest" cvs update
Index: login.c
===
RCS file: /home2/cvsroot/ccvs/src/login.c,v
retrieving revision 1.56
diff -r1.56 login.c
120a121
> char *passenv;
145,146c146,154
< typed_password = getpass ("CVS password: ");
< typed_password = scramble (typed_password);
---
> passenv = getenv ("CVSPASSWORD");
> if (passenv) {
> passenv = xstrdup (passenv);
> typed_password = scramble (passenv);
> }
> else {
> typed_password = getpass ("CVS password: ");
> typed_password = scramble (typed_password);
> }
Re: CVS Delete ALl Files
> 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
Re: WinCvs users - query
> > Formatting is not stored anyway, so there is nothing to feel sorry about. Being able to write ChangeLog in HTML woul be useful.
