Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!iwarp.intel.com!news
From: merlyn@iwarp.intel.com (Randal Schwartz)
Newsgroups: comp.unix.questions
Subject: SCCS misinformation Rumor-Control (was Re: RCS vs. SCCS)
Message-ID: <1990Mar20.172303.7647@iwarp.intel.com>
Date: 20 Mar 90 17:23:03 GMT
References: <1990Mar15.204111.4923@csmil.umich.edu> <2265@tellab5.tellabs.com>
Sender: news@iwarp.intel.com
Reply-To: merlyn@iwarp.intel.com (Randal Schwartz)
Organization: Stonehenge; netaccess via Intel, Beaverton, Oregon, USA
Lines: 21
In-Reply-To: segel@tellab5.tellabs.com (Mike Segel)

In article <2265@tellab5.tellabs.com>, segel@tellab5 (Mike Segel) writes:
|    SCCS uses forward deltas. This means that when you "check in"
|    a piece of code, the original is stored, and the later copies
|    are really deltas based on the original.

Ack. Pthpth. Not this bad piece of misinformation going around *again*.

SCCS uses a method that can get it to any delta *equally well*, (or
equally poorly, depending on your bent).  It doesn't lean in the
backwards or forwards direction *at* *all*.  Just 'cuz the doc sez
something like "noticing the differences" doesn't mean it's storing
them that way.  Internally, it uses something like tagged lines, and
it pulls out all the lines in order that match a particular mix,
computed as a function of the delta that you asked it to generate.

Just another SCCS/RCS/whatever user,
-- 
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III      |
| merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/