Re: sccs2rcs to perl
Michael Sterrett -Mr. Bones.- writes: > > It would be nice to receive some comment from the CVS development team. > This is the third time I've sent this out the the mailing lists with not > a peep from anyone about it. Very disappointing. contrib/README: "Unsupported" also means that no one has volunteered to accept and check in changes to this directory. So submissions for new scripts to add here are unlikely to be accepted. Suggested changes to the existing scripts here conceivably might, but that isn't clear either, unless of course they come from the original author of the script. If you have some software that works with CVS that you wish to offer it is suggested that you make it available by FTP or HTTP and then announce it on the info-cvs mailing list. -Larry Jones You can never really enjoy Sundays because in the back of your mind you know you have to go to school the next day. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Larry Jones wrote: > contrib/README: > > "Unsupported" also means that no one has volunteered to accept and check > in changes to this directory. So submissions for new scripts to add > here are unlikely to be accepted. Suggested changes to the existing > scripts here conceivably might, but that isn't clear either, unless of > course they come from the original author of the script. > > If you have some software that works with CVS that you wish to offer it > is suggested that you make it available by FTP or HTTP and then announce > it on the info-cvs mailing list. > > -Larry Jones Larry -- Thanks for the response. I guess I'm just a little naive when it comes to the development process of CVS. I assumed that any sort of improvement to the distribution would be welcome. In my involvement in open source projects in the past, the maintainers of the projects have been very receptive and pleased to receive code, which they didn't have to write. I see a problem with the CVS code as distributed. That is, it has a single csh script which is both slow and makes the CVS code-base depend on an additional unix "utility" when it doesn't have to. I believe I addressed both of these problems with my re-write of the script in perl. I've announced it on the info-cvs list (a couple of times now) and I'd like to make it available via FTP in the CVS distribution if I could just get some cooperation from you, Derek or one of the other silent CVS developers. Thanks, Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Michael Sterrett -Mr. Bones.- writes: > > I see a problem with the CVS code as distributed. That is, it has > a single csh script which is both slow and makes the CVS code-base > depend on an additional unix "utility" when it doesn't have to. > I believe I addressed both of these problems with my re-write of the > script in perl. I've announced it on the info-cvs list (a couple > of times now) and I'd like to make it available via FTP in the CVS > distribution if I could just get some cooperation from you, Derek or > one of the other silent CVS developers. Anybody with sccs, CVS, make, and perl almost certainly already has csh, too. The fact that the existing script is slow is irrelevant -- you generally convert your files just once, who cares whether it takes one hour or two? Perl scripts of any complexity are notorious for only running right on the exact version of perl they were written on and, so far as I can tell, your script has not been tested by anyone other than you. And given the stunning lack of interest shown here, it seems that no one really cares. So, while I'm sure you think it's wonderful and it sounds like it was a big benefit to you, I don't any value to adding it to the CVS distribution. -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Larry Jones wrote: > Anybody with sccs, CVS, make, and perl almost certainly already has csh, Well, I don't - at least, I wouldn't if I didn't have to because CVS depends on csh *only* because of the sccs2rcs csh script. I'd love to remove csh from my system, but that would break dependencies (which is primarily why I re-wrote it in the first place). > And given the stunning lack of interest shown here, it seems that > no one really cares. So, while I'm sure you think it's wonderful and it > sounds like it was a big benefit to you, I don't any value to adding it > to the CVS distribution. Ok, let me try another idea on you then. Given the stunning lack of interest which, I admit certainly seems evident, how would you feel about removing the sccs2rcs script from the CVS distribution? That'd make me just as happy. All future CVS distribution gets smaller and you won't have to deal with any future bugs in the sccs2rcs script (which I see you had to patch a couple of times in the last year) -- everybody comes out a winner. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 16:46:04 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > I see a problem with the CVS code as distributed. That is, it has > a single csh script which is both slow and makes the CVS code-base > depend on an additional unix "utility" when it doesn't have to. Well, it's only a contributed utility, not a core part of the CVS code as distributed. > I believe I addressed both of these problems with my re-write of the > script in perl. No, you did not. Only a translation to POSIX Shell or C would have addressed both problems. While the translation to perl may have made the script run faster, it only changed the reliance on one semi-standard tool to another less standard tool (perl is neither commonly available on all unix platforms, nor is it terribly small and fast, though it may be faster than csh). -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Greg A. Woods wrote: > [ On Thursday, March 7, 2002 at 16:46:04 (-0500), Michael Sterrett -Mr. Bones$ > > Subject: Re: sccs2rcs to perl > > > > I see a problem with the CVS code as distributed. That is, it has > > a single csh script which is both slow and makes the CVS code-base > > depend on an additional unix "utility" when it doesn't have to. > > Well, it's only a contributed utility, not a core part of the CVS code > as distributed. All the Linux distributions I have access too include sccs2rcs as part of the CVS package because it is distributed as part of the CVS tar ball. Because of that, I consider it "part of CVS". > > I believe I addressed both of these problems with my re-write of the > > script in perl. > > No, you did not. Only a translation to POSIX Shell or C would have > addressed both problems. Sorry, but I disagree. There are already a number of perl scripts in the contrib directory so the package as a whole depends on perl already. I don't think you can argue that I've not reduced the number of dependencies for the CVS package. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 17:21:08 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > Well, I don't - at least, I wouldn't if I didn't have to because CVS > depends on csh *only* because of the sccs2rcs csh script. I'd love to > remove csh from my system, but that would break dependencies (which is > primarily why I re-wrote it in the first place). I removed csh from almost all of my systems long ago. I still have no interest in re-writing sccs2rcs into perl though :-) (I don't think I would ever use sccs2rcs.csh either -- I'd write my own conversion tool in POSIX shell if I had to, even though it would be trivial for me to either install csh again or find a machine where it is still present and working) > Ok, let me try another idea on you then. Given the stunning lack of > interest which, I admit certainly seems evident, how would you feel about > removing the sccs2rcs script from the CVS distribution? That'd make me > just as happy. All future CVS distribution gets smaller and you won't have > to deal with any future bugs in the sccs2rcs script (which I see you had to > patch a couple of times in the last year) -- everybody comes out a winner. I wouldn't have any objection to that! ;-) -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 18:06:22 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > All the Linux distributions I have access too include sccs2rcs as part > of the CVS package because it is distributed as part of the CVS tar ball. > Because of that, I consider it "part of CVS". Unless you have SCCS files you wouldn't even know about it -- it's hardly a "part of CVS", especially since it's explicitly only included in the "contrib" sub-directory. > Sorry, but I disagree. There are already a number of perl scripts in the > contrib directory so the package as a whole depends on perl already. That's also irrelevant. You need to consider that the things in the "contrib" subdirectory are individual stand-alone things -- not related to each other (well, there are some that are related to each other, but most are completly independent), and only minimally related to CVS (sccs2rcs is only related very indirectly in that the RCS files it creates can be used by CVS). CVS itself, as a whole, does not depend on perl in any what whatsoever. > I don't think you can argue that I've not reduced the number of > dependencies for the CVS package. The "contrib" things are not really a part of the CVS package -- they're just a collection of things that were contributed but explicitly _not_ added to the package proper. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Greg A. Woods wrote: > I removed csh from almost all of my systems long ago. Ah, I envy you. :-) I refuse to ignore the package dependencies on my systems though... > I still have no interest in re-writing sccs2rcs into perl though :-) Well, I did it for two reasons: 1. the package dependencies (which I guess you don't mind ;-)) 2. I have a bunch of SCCS directories I need to convert to RCS and the csh version of the script is way too slow. > (I don't think I would ever use sccs2rcs.csh either -- I'd write my own > conversion tool in POSIX shell if I had to, even though it would be > trivial for me to either install csh again or find a machine where it is > still present and working) Ah, someone who dislikes csh even more than I do. > > I wouldn't have any objection to that! ;-) Great! Two votes for... Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 18:40:03 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > 2. I have a bunch of SCCS directories I need to convert to RCS and the >csh version of the script is way too slow. Is? "was"? :-) Why convert from SCCS? I don't have any larger projects managed by SCCS, but for all the small ones I have there's not much point to changing over to RCS (or CVS) -- I just keep using SCCS :-) -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Fri, Mar 08, 2002 at 10:55:37AM -0800, Stephen Rasku wrote: > > I believe what he is refering to is that the more SCCS will get slower the > more revisions you have in a file. Getting a file from RCS/CVS should be a > constant time event for the latest version because RCS/CVS stores the latest > revision verbatim. However, as I understand it, SCCS saves each version as > "#ifdefs". I don't think it stores a complete copy of the latest revision. Almost: SCCS stores the first version ad verbatim, followed by a delta for each version (=revision in RCS-speak). #ifdefs is a C (/C++?) thing. > As such, it will have to calculate what is in the latest version and how long > this takes will depend on how many revisions you have. -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com /"\ \ / ASCII Ribbon Campaign x - Say NO to HTML in email / \ - Say NO to Word documents in email (and Macros!) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Karl E. Jorgensen writes: > > Almost: SCCS stores the first version ad verbatim, followed by a delta > for each version (=revision in RCS-speak). No, it most certainly does not. SCCS stores all of the versions in an interleaved form, something like: #inserted in revision 1: line 1 line 2 #inserted in revision 2: line 2a line 2b #end revision 2 line 3 line 4 #removed in revision 3: line 5 line 6 #end revision 3 line 7 line 8 line 9 #end revision 1 So, *no* version is stored ad verbatim, there are no "diffs" per se, and it takes almost exactly the same time to retrieve any revision. -Larry Jones It's either spectacular, unbelievable success, or crushing, hopeless defeat! There is no middle ground! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Greg A. Woods wrote: > Why convert from SCCS? I don't have any larger projects managed by SCCS, > but for all the small ones I have there's not much point to changing over > to RCS (or CVS) -- I just keep using SCCS :-) Ok, well this is moving away from the topic I'd prefer, that being the sccs2rcs script issue, but... Well, at this moment, we have 1835 SCCS directories and an absolute ton of source. SCCS isn't the fastest thing to use -- I believe RCS blows it out of the water in the most common case of getting the most recent version out of the repository -- especially on NFS mounted disk, this gets to be an issue. Perhaps more importantly, our development is moving almost entirely to Linux and the free SCCS support on Linux is lacking (CSSC isn't recommended by the author). We'd also like to completely change our development scheme and move to CVS with maintainers of various subsystems accepting patches from developers similar to the free software model, but in-house. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Michael Sterrett -Mr. Bones.- writes: > > Well, at this moment, we have 1835 SCCS directories and an absolute ton > of source. SCCS isn't the fastest thing to use -- I believe RCS blows > it out of the water in the most common case of getting the most recent > version out of the repository -- especially on NFS mounted disk, this > gets to be an issue. You may find your belief to be mistaken -- I can't think of any reason to expect CVS to be faster than SCCS, unless you plan to switch from NFS access to CVS's client/server mode (which I would strongly advise -- we have had lots of reports of repository corruption caused by NFS interoperability problems). -Larry Jones Things are never quite as scary when you've got a best friend. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
>Subject: Re: sccs2rcs to perl >To: [EMAIL PROTECTED] (Michael Sterrett -Mr. Bones.-) >Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] >From: [EMAIL PROTECTED] (Larry Jones) >List-Archive: <http://mail.gnu.org/pipermail/bug-cvs/> >Date: Fri, 8 Mar 2002 13:39:01 -0500 (EST) > >Michael Sterrett -Mr. Bones.- writes: >> >> Well, at this moment, we have 1835 SCCS directories and an absolute ton >> of source. SCCS isn't the fastest thing to use -- I believe RCS blows >> it out of the water in the most common case of getting the most recent >> version out of the repository -- especially on NFS mounted disk, this >> gets to be an issue. > >You may find your belief to be mistaken -- I can't think of any reason >to expect CVS to be faster than SCCS, unless you plan to switch from NFS >access to CVS's client/server mode (which I would strongly advise -- we >have had lots of reports of repository corruption caused by NFS >interoperability problems). > I believe what he is refering to is that the more SCCS will get slower the more revisions you have in a file. Getting a file from RCS/CVS should be a constant time event for the latest version because RCS/CVS stores the latest revision verbatim. However, as I understand it, SCCS saves each version as "#ifdefs". I don't think it stores a complete copy of the latest revision. As such, it will have to calculate what is in the latest version and how long this takes will depend on how many revisions you have. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Stephen Rasku writes: > > I believe what he is refering to is that the more SCCS will get slower the > more revisions you have in a file. Getting a file from RCS/CVS should be a > constant time event for the latest version because RCS/CVS stores the latest > revision verbatim. However, as I understand it, SCCS saves each version as > "#ifdefs". I don't think it stores a complete copy of the latest revision. > As such, it will have to calculate what is in the latest version and how long > this takes will depend on how many revisions you have. SCCS can retrieve any revision in one pass through the file. As you say, there are the equivalent of "#ifdefs" that specify which revisions include the following lines , so there's very little processing time, it's mostly just I/O time. CVS as currently implemented has to read the entire RCS file before doing anything, so I'd be very surprised if it's significantly faster. -Larry Jones Life's a lot more fun when you're not responsible for your actions. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Larry Jones wrote: >Stephen Rasku writes: >> >> I believe what he is refering to is that the more SCCS will get slower the >> more revisions you have in a file. Getting a file from RCS/CVS should be >> a constant time event for the latest version because RCS/CVS stores the >> latest revision verbatim. However, as I understand it, SCCS saves each >> version as "#ifdefs". I don't think it stores a complete copy of the >> latest revision. As such, it will have to calculate what is in the latest >> version and how long this takes will depend on how many revisions you >> have. > >SCCS can retrieve any revision in one pass through the file. As you >say, there are the equivalent of "#ifdefs" that specify which revisions >include the following lines , so there's very little processing time, >it's mostly just I/O time. CVS as currently implemented has to read the >entire RCS file before doing anything, so I'd be very surprised if it's >significantly faster. Really? Looking at a sample ,v file I can see the latest revision stored intact near the top of the file. I don't know why it would have to read the other revisions. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Friday, March 8, 2002 at 13:24:16 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > Well, at this moment, we have 1835 SCCS directories and an absolute ton > of source. SCCS isn't the fastest thing to use -- I believe RCS blows > it out of the water in the most common case of getting the most recent > version out of the repository -- especially on NFS mounted disk, this > gets to be an issue. You really had better research that a bit more. You are apparently suffering from belief in a widely disseminated myth (caused by an incorrect answer remaining in the comp.unix.questions FAQ since 1992, perhaps because my colleague Ted Timar, who maintained that FAQ, was not a huge fan of SCCS). SCCS is not necessarily slower than RCS -- and RCS _is_ still slower than SCCS in many cases, esp. if you use one of the more modern SCCS implementations, such as Larry McVoy's BitSCCS, or Ross Ridge's MySC, or even the GNU CSSC. A common misconception is that SCCS baselines the initial version and keeps deltas to create newer versions. Actually, SCCS interleaves all the versions; this is not as bad as the common misconception, but it _can_ make new development get progressively slower. Note though that if you don't use the head of the trunk for development then RCS can degrade rather nastily In other words you'd better benchmark before you decide on that assumption alone. BTW, what the heck are you doing with putting any kind of repository on an NFS partition!?!?!?!? > Perhaps more importantly, our development is moving almost entirely to > Linux and the free SCCS support on Linux is lacking (CSSC isn't recommended > by the author). The current maintainer of CSSC is overly careful. I've been using it happily for years, even on occasion interoperating with it and SunOS-4. > We'd also like to completely change our development scheme and move to CVS > with maintainers of various subsystems accepting patches from developers > similar to the free software model, but in-house. Well, there could be benefits there, I grant you that! -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Fri, 8 Mar 2002, Larry Jones wrote: > SCCS can retrieve any revision in one pass through the file. As you > say, there are the equivalent of "#ifdefs" that specify which revisions > include the following lines , so there's very little processing time, > it's mostly just I/O time. CVS as currently implemented has to read the > entire RCS file before doing anything, so I'd be very surprised if it's > significantly faster. Larry -- When was the last time you used SCCS for a large project? RCS is *way* faster, at least at getting the latest version of the file for edit. It's not super easy for me to test right now, but I imagine CVS is equally quick. All of this discussion is interesting to me, but what I'd really like to see is something done about the sccs2rcs script. Is there any real gain in continuing to ship it with CVS given the fact that it doesn't seem to be maintained by anyone (at least, no one wants to take responsibility for it) and it doesn't pertain to the main functionality of CVS? Why not move it to http://www.loria.fr/~molli/cvs-index.html as contrib/README suggests and out of the official CVS tarball releases? What's your opinion of this idea? Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Michael Sterrett wrote: >All of this discussion is interesting to me, but what I'd really >like to see is something done about the sccs2rcs script. Is >there any real gain in continuing to ship it with CVS given the >fact that it doesn't seem to be maintained by anyone (at least, >no one wants to take responsibility for it) and it doesn't >pertain to the main functionality of CVS? Why not move it to >http://www.loria.fr/~molli/cvs-index.html as contrib/README >suggests and out of the official CVS tarball releases? What's >your opinion of this idea? Personally, I think we should continue to include the current script. I used it successfully to convert our SCCS code repository from SCCS to CVS without any problems and I think a lot of people have. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Stephen Rasku writes: > > Really? Looking at a sample ,v file I can see the latest revision stored > intact near the top of the file. I don't know why it would have to read the > other revisions. I didn't say it has to, I said it does. It makes the code simpler to get all the data from the RCS file into a nice internal data structure. -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Michael Sterrett -Mr. Bones.- writes: > > When was the last time you used SCCS for a large project? RCS is *way* > faster, at least at getting the latest version of the file for edit. > It's not super easy for me to test right now, but I imagine CVS is > equally quick. You imagine wrong. There are significant differences between RCS and CVS's RCS library. -Larry Jones Temporary insanity! That's all it was! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
