Re: sccs2rcs to perl
[EMAIL PROTECTED] (Larry Jones) writes: 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. It was not the case formerly that CVS read the entire RCS file to retrieve the head revision. I haven't looked at the current code. But previously CVS would just read the RCS header (including all the tags), and then only read revision text as required. Ian ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Hi Michael. 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 run Red Hat 6.2 here, with CVS installed from RPM. I've just checked, and no such file exists either on my system or in the CVS RPM. Could you advise where it's gone please? 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. If somebody wishes to send me a copy of the script in question, I'll translate it to bash for you if that's possible. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Ian Lance Taylor writes: It was not the case formerly that CVS read the entire RCS file to retrieve the head revision. I haven't looked at the current code. But previously CVS would just read the RCS header (including all the tags), and then only read revision text as required. That's partially true -- CVS does just read the header to start, but whenever it needs to read any revision text, it reads all of it. -Larry Jones Even though we're both talking english, we're not speaking the same language. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
On Fri, 8 Mar 2002, Riley Williams wrote: 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 run Red Hat 6.2 here, with CVS installed from RPM. I've just checked, and no such file exists either on my system or in the CVS RPM. Could you advise where it's gone please? I don't think you have the rpm distributed with Red Hat 6.2: $ rpm -qlp cvs-1.10.7-7.i386.rpm | grep sccs /usr/lib/cvs/contrib/sccs2rcs If somebody wishes to send me a copy of the script in question, I'll translate it to bash for you if that's possible. Sounds good to me, I'll send you the original csh version to you via private email and we'll see what Larry has to say about it. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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 ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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 ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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 ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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 ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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 ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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 ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
[EMAIL PROTECTED] (Larry Jones) writes: Ian Lance Taylor writes: It was not the case formerly that CVS read the entire RCS file to retrieve the head revision. I haven't looked at the current code. But previously CVS would just read the RCS header (including all the tags), and then only read revision text as required. That's partially true -- CVS does just read the header to start, but whenever it needs to read any revision text, it reads all of it. No, CVS doesn't read the whole RCS file. Look closely at RCS_checkout and RCS_deltas. They stop reading once they have the text they need. Ian ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
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 ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Hi Michael. Hi Riley -- Thanks for the reply. At least now I know that my mail is being seen by someone other than myself. NP. Let me address your points at they go... I'm not on the CVS development team as such, just being a very happy user of CVS... Oh, don't be fooled -- I'm a very happy user of CVS too. I just use SCCS in my day job because that's what we've always used, but that's changing these days -- mostly with the help of the sccs2rcs perl script that I included before. As stated in my original email, I never managed to get on with SCCS on the only occasion I was expected to use it, so can't really comment on it in any sort of meaningful way... ...but I would like to offer one possible reason for the lack of comments: Perhaps those on the list here are like me and don't use SCCS in the first place, so have no use for the script. True, that could be a reason, but you may be missing the fact that I'm not advocating the *addition* of a script, but a *replacement* of a script. If you think about it, you'll soon realise that the difference you refer to is irrelevant to anybody who doesn't use SCCS - if they don't use SCCS, then they will have no interest whatsoever in the existence of a script to convert from SCCS to CVS, much less in how well (or even whether) the script in question works. If you check your CVS distribution, you'll find in the contrib directory a sccs2rcs script *already* there. However, it is written in csh which is A) slow B) one more dependency for your .deb or .rpm to depend on. The perl script that I'm requesting consideration addresses both of these issues since the perl script runs about twice as fast as the csh version and, since there are already perl scripts in the CVS distribution, adds *no* additional dependencies. To get any comments on either your script or the original one, you'd need to find somebody else who uses both SCCS and CVS and needs to convert from SCCS to CVS. Other than that, to be honest, nobody's going to be interested for the simple reason that they've no reasonable means to test either script. Another possibility is the length of the To: and CC: list in your email - I know several people who have their system set up to auto-kill any emails with more than three names in those two combined simply as a way to cut down the amount of mail they have to handle, and your email would not have made it to any of them. I have sent this email already twice before -- once to bug-cvs and once to user-cvs with very reasonable To: and CC: lines so I don't think this is the reason. I'm on the bug-cvs list but not on the user-cvs list, and I've never seen your email before the one I replied to. I've been on the bug-cvs list since last September, so wouldn't have seen it if posted before then, but if posted since, it apparently didn't get through to that list, which could explain the lack of response... I've also written to Larry Jones (who seems to be the primary person committing to the CVS source tree) directly and I got *no* reply - not even a go away or not interested! That much I can't comment on as I don't know Larry's circumstances. However, if they're anything like me, he probably doesn't have the time to even read, much less reply to, emails about things he's not directly interested in. To put that in context, allow that (after my spam-filter has finished with them) I receive between 500 and 700 emails a day, mostly from the Linux-Kernel or the UK-Genealogy mailing lists, and if I even read every email I received, I'd have little time to do anything else. As it happens, I read every mail posted to the Linux-8086, Linux-Hams and Bug-CVS mailing lists, but I only reply to ones where I can make a positive contribution of some sort. With most of the mailing lists I receive, I decide whether to read a particular email based on (a) the sender is somebody important on that list (I read EVERY email from either Linus Torvalds or Alan Cox on the Linux-Kernel list), or (b) the subject line catches my attention. If neither of those apply, the email doesn't get read - it's as simple as that. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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). chop 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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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. Chop my suggestion that sccs2rcs be removed from the cvs distribution I wouldn't have any objection to that! ;-) Great! Two votes for... Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-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] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
sccs2rcs to perl
My monthly resend of this script.
I guess I'll include the script directly this time in the hopes that
maybe people don't like attachments and that's the reason I still haven't
gotten a response from anyone in the CVS development team. The script
(sccs2rcs.in) is attached in-line after the original message.
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.
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
On Thu, 3 Jan 2002, Michael Sterrett -Mr. Bones.- wrote:
Please consider adding this re-write of sccs2rcs to the contrib directory.
This re-write in perl:
o runs in about half the time of the csh version (which is going to
make our local conversion more pleasant)
o uses no temporary files in /tmp (still leaves the log there)
o adds no additional package dependency (for deb and rpm, etc.)
since there are several perl scripts already in contrib
o removes the package dependency on csh (for deb and rpm, etc.)
Other notes:
I've added support for %P% = $Source$ which we use here, but was
missing from the original script.
I've updated the tested under comment at the top of the script
to reflect my own testing - I don't have access to an Ultrix box,
but this script should work there.
The output is slightly different from the csh script in that I've
removed the printing of the initial ci command without description.
It seemed inconsistent to me since none of the other commands were
printed. Also, during testing, it made it easier to compare the
results of the csh script and the perl script as I've chosen to use
the -m option to ci (supported on all the architectures to which I
have access).
Thanks,
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
P.S. Derek, Larry -- you guys got this directly since you seemed to be
the ones most likely to check something in based on browsing the history
in contrib. Sorry if sending to you directly is a faux pas.
--CUT---
#! @PERL@ -w
# -*-Perl-*-
use strict;
#
# Sccs2rcs is a script to convert an existing SCCS history into an RCS
# history without losing any of the information contained therein.
# It has been tested under the following OS's:
# SunOS 4.1.3 5.6 5.7
# Linux
#
# Things to note:
# + It will NOT delete or alter your ./SCCS history under any
# circumstances.
#
# + Run in a directory where ./SCCS exists and where you can
# create ./RCS
#
# + /usr/local/bin is put in front of the default path.
# (SCCS under Ultrix is set-uid sccs, bad bad bad, so
# /usr/local/bin/sccs here fixes that)
#
# + Date, time, author, comments, branches, are all preserved.
#
# + If a command fails somewhere in the middle, it bombs with
# a message -- remove what it's done so far and try again.
# rm -rf RCS; sccs unedit `sccs tell`; sccs clean
# There is no recovery and exit is far from graceful.
# If a particular module is hanging you up, consider
# doing it separately; move it from the current area so that
# the next run will have a better chance or working.
# Also (for the brave only) you might consider hacking
# the s-file for simpler problems: I've successfully changed
# the date of a delta to be in sync, then run sccs admin -z
# on the thing.
#
# + After everything finishes, ./SCCS will be moved to ./old-SCCS.
#
# This file may be copied, processed, hacked, mutilated, and
# even destroyed as long as you don't tell anyone you wrote it.
#
# Ken Cox
# Viewlogic Systems, Inc.
# [EMAIL PROTECTED]
# ...!harvard!cg-atla!viewlog!kenstir
#
# Various hacks made by Brian Berliner before inclusion in CVS contrib area.
# Converted to perl by Michael Sterrett - [EMAIL PROTECTED]
# Hard to tell if that should be filed under mutilated or destroyed.
# Globals
#
my $logfile = /tmp/sccs2rcs_${$}_log;
# Could have used a hash for the keywords except we want to guarantee
# the order
my @sccs_keywords = (
'%W%[ ]*%G%',
'%W%[ ]*%E%',
'%W%',
'%Z%%M%[]*%I%[ ]*%G%',
'%Z%%M%[]*%I%[ ]*%E%',
'%M%[ ]*%I%[ ]*%G%',
'%M%[ ]*%I%[ ]*%E%',
'%M%',
'%I%',
'%G%',
'%E%',
'%U%',
'%P%'
);
# This is used for checking if we need to do keyword substitution or not.
my $big_sccs_pattern = join('|', @sccs_keywords);
# the quotes surround the dollar signs to fool RCS when I check in this script
my @rcs_keywords = (
'$'.'Id'.'$',
'$'.'Id'.'$',
'$'.'Id'.'$',
'$'.'SunId'.'$',
'$'.'SunId'.'$',
'$'.'Id'.'$',
'$'.'Id'.'$',
'$'.'RCSfile'.'$',
'$'.'Revision'.'$',
'$'.'Date'.'$',
'$'.'Date'.'$',
'',
'$'.'Source
Re: sccs2rcs to perl
Hi Michael. My monthly resend of this script. I guess I'll include the script directly this time in the hopes that maybe people don't like attachments and that's the reason I still haven't gotten a response from anyone in the CVS development team. The script (sccs2rcs.in) is attached in-line after the original message. 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. I'm not on the CVS development team as such, just being a very happy user of CVS, but I would like to offer one possible reason for the lack of comments: Perhaps those on the list here are like me and don't use SCCS in the first place, so have no use for the script. Another possibility is the length of the To: and CC: list in your email - I know several people who have their system set up to auto-kill any emails with more than three names in those two combined simply as a way to cut down the amount of mail they have to handle, and your email would not have made it to any of them. I will add that at University not so long ago, we were expected to use SCCS for our CS projects, but I coul;dn't get the hang of using SCCS there, so never made any real use of it. I don't know whether this was SCCS in general or the way they had it set up, as I've never even looked at using it elsewhere, but I do know that I was using CVS shortly after coming across it and installing it on my RedHat Linux system. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Hi Riley -- Thanks for the reply. At least now I know that my mail is being seen by someone other than myself. Let me address your points at they go... On Wed, 6 Mar 2002, Riley Williams wrote: I'm not on the CVS development team as such, just being a very happy user of CVS Oh, don't be fooled -- I'm a very happy user of CVS too. I just use SCCS in my day job because that's what we've always used, but that's changing these days -- mostly with the help of the sccs2rcs perl script that I included before. but I would like to offer one possible reason for the lack of comments: Perhaps those on the list here are like me and don't use SCCS in the first place, so have no use for the script. True, that could be a reason, but you may be missing the fact that I'm not advocating the *addition* of a script, but a *replacement* of a script. If you check your CVS distribution, you'll find in the contrib directory a sccs2rcs script *already* there. However, it is written in csh which is A) slow B) one more dependency for your .deb or .rpm to depend on. The perl script that I'm requesting consideration addresses both of these issues since the perl script runs about twice as fast as the csh version and, since there are already perl scripts in the CVS distribution, adds *no* additional dependencies. Another possibility is the length of the To: and CC: list in your email - I know several people who have their system set up to auto-kill any emails with more than three names in those two combined simply as a way to cut down the amount of mail they have to handle, and your email would not have made it to any of them. I have sent this email already twice before -- once to bug-cvs and once to user-cvs with very reasonable To: and CC: lines so I don't think this is the reason. I've also written to Larry Jones (who seems to be the primary person committing to the CVS source tree) directly and I got *no* reply - not even a go away or not interested! Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
sccs2rcs to perl
Please consider adding this re-write of sccs2rcs to the contrib directory.
This re-write in perl:
o runs in about half the time of the csh version (which is going to
make our local conversion more pleasant)
o uses no temporary files in /tmp (still leaves the log there)
o adds no additional package dependency (for deb and rpm, etc.)
since there are several perl scripts already in contrib
o removes the package dependency on csh (for deb and rpm, etc.)
Other notes:
I've added support for %P% = $Source$ which we use here, but was
missing from the original script.
I've updated the tested under comment at the top of the script
to reflect my own testing - I don't have access to an Ultrix box,
but this script should work there.
The output is slightly different from the csh script in that I've
removed the printing of the initial ci command without description.
It seemed inconsistent to me since none of the other commands were
printed. Also, during testing, it made it easier to compare the
results of the csh script and the perl script as I've chosen to use
the -m option to ci (supported on all the architectures to which I
have access).
Thanks,
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
P.S. Derek, Larry -- you guys got this directly since you seemed to be
the ones most likely to check something in based on browsing the history
in contrib. Sorry if sending to you directly is a faux pas.
#! @PERL@ -w
# -*-Perl-*-
use strict;
#
# Sccs2rcs is a script to convert an existing SCCS history into an RCS
# history without losing any of the information contained therein.
# It has been tested under the following OS's:
# SunOS 4.1.3 5.6 5.7
# Linux
#
# Things to note:
# + It will NOT delete or alter your ./SCCS history under any
# circumstances.
#
# + Run in a directory where ./SCCS exists and where you can
# create ./RCS
#
# + /usr/local/bin is put in front of the default path.
# (SCCS under Ultrix is set-uid sccs, bad bad bad, so
# /usr/local/bin/sccs here fixes that)
#
# + Date, time, author, comments, branches, are all preserved.
#
# + If a command fails somewhere in the middle, it bombs with
# a message -- remove what it's done so far and try again.
# rm -rf RCS; sccs unedit `sccs tell`; sccs clean
# There is no recovery and exit is far from graceful.
# If a particular module is hanging you up, consider
# doing it separately; move it from the current area so that
# the next run will have a better chance or working.
# Also (for the brave only) you might consider hacking
# the s-file for simpler problems: I've successfully changed
# the date of a delta to be in sync, then run sccs admin -z
# on the thing.
#
# + After everything finishes, ./SCCS will be moved to ./old-SCCS.
#
# This file may be copied, processed, hacked, mutilated, and
# even destroyed as long as you don't tell anyone you wrote it.
#
# Ken Cox
# Viewlogic Systems, Inc.
# [EMAIL PROTECTED]
# ...!harvard!cg-atla!viewlog!kenstir
#
# Various hacks made by Brian Berliner before inclusion in CVS contrib area.
# Converted to perl by Michael Sterrett - [EMAIL PROTECTED]
# Hard to tell if that should be filed under mutilated or destroyed.
# Globals
#
my $logfile = /tmp/sccs2rcs_${$}_log;
# Could have used a hash for the keywords except we want to guarantee
# the order
my @sccs_keywords = (
'%W%[ ]*%G%',
'%W%[ ]*%E%',
'%W%',
'%Z%%M%[]*%I%[ ]*%G%',
'%Z%%M%[]*%I%[ ]*%E%',
'%M%[ ]*%I%[ ]*%G%',
'%M%[ ]*%I%[ ]*%E%',
'%M%',
'%I%',
'%G%',
'%E%',
'%U%',
'%P%'
);
# This is used for checking if we need to do keyword substitution or not.
my $big_sccs_pattern = join('|', @sccs_keywords);
# the quotes surround the dollar signs to fool RCS when I check in this script
my @rcs_keywords = (
'$'.'Id'.'$',
'$'.'Id'.'$',
'$'.'Id'.'$',
'$'.'SunId'.'$',
'$'.'SunId'.'$',
'$'.'Id'.'$',
'$'.'Id'.'$',
'$'.'RCSfile'.'$',
'$'.'Revision'.'$',
'$'.'Date'.'$',
'$'.'Date'.'$',
'',
'$'.'Source'.'$'
);
# Subroutines
#
sub error_exit()
{
print(\n\nDanger! Danger!\n);
print(Some command exited with a non-zero exit status.\n);
print(Log file exists in $logfile.\n\n);
print(Incomplete history in ./RCS -- remove it\n);
print(Original unchanged history in ./SCCS\n);
exit(1);
}
# This routine is used by the Schwartzian Transform in the main loop
sub by_version
{
my $limit = ($#{$a} $#{$b}) ? $#{$b} - 1 : $#{$a} - 1;
for (my $c = 0; $c = $limit; $c++) {
my $x = ($a-[$c] = $b-[$c]);
return $x if ($x
