13 Sep
2019
13 Sep
'19
10:11 a.m.
On Thu, Sep 12, 2019 at 02:44:45PM +0100, Tony Finch wrote:
Larry McVoy <lm(a)mcvoy.com> wrote:
Yeah, you are right. The most recent version should be fast. SCCS reads
the whole file and RCS does not in the common case.
But here is an SCCS win. SCCS has a 16 bit ignore the carry bit checksum
over the whole file. RCS has none of that.
You can argue that a 16 bit checksum is not good enough in this day of
md5sums, sha1 hashes, crcs, etc.
There are two places where it is great.
A) Memory errors. Memory chips errors are none, parity, or ECC.
Parity has gone the way of the doodoo bird so we have none or ECC. I can
pretty much promise you that the machine you are reading this on has no
error detection or correction. Only high end servers have ECC.
That SCCS checksum is awesome because we can print out what the checksum
should be and what we got. If it differs in a power of two then it is
a single bit error and that is your memory sucks. I can't tell you how
many times customers said something was wrong and I made them run a
memory check and it was their memory. 100's is too small, 1000's
at least.
B) NFS errors. So all NFS implementations, Suns included, had a bad
habit of returning a block of nulls. I dunno why but that is a thing.
The SCCS checksum would detect that. RCS and CVS did not have a checksum
so when NFS returned garbage, they were happy to return that to you.
It's really surprising how well the SCCS checksum has worked. When we
went to a binary format we did CRC on each block and XOR so we could
put stuff back together. I still have a lot of respect for that little
checksum. It served us well.
--lm
If you have actual data that shows RCS to be
faster I would like to
see that. RCS read the whole file. It could have been faster, it could
have put the offset into the file where the most recent version begain.
But it didn't. It read the entire file.
In RCS the most recent version of the file is near the start of the ,v
file after a list of revisions, so it doesn't have to read the deltas for
the common case of checking out the current version of a file. I think
there must be a similar optimization to copy the deltas without processing
them when committing a new revision. But yes, as soon as you get away from
working on the latest revision of the main branch, RCS becomes
quadratically slow.