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 imagi
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
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:
lin
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 lat
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 leas
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 curr
[ 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
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
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
>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:
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 -- es
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 pr
[ 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
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:
[ 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.
> Bec
[ 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 lov
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
[ 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
>
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
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
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 conce
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 h
22 matches
Mail list logo
