From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 8558630FE3 for ; Fri, 13 Dec 2024 22:47:44 +0100 (CET) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 3680F42765; Sat, 14 Dec 2024 07:47:39 +1000 (AEST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by minnie.tuhs.org (Postfix) with ESMTPS id C5A5C42763 for ; Sat, 14 Dec 2024 07:47:34 +1000 (AEST) Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-4afdf096fc5so476378137.2 for ; Fri, 13 Dec 2024 13:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1734126454; x=1734731254; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QTM8hNknJIeEkNf5MHdFtcyvDpU7J7d0jQYxJZBz0DE=; b=q3gHKDmLH0ITW8EjoSjEtQnsJjw57EMLzZkzk5mN478pzwLPRKigQhdUumfoyPoZiU sE9+K0aU7kBnE7mkEMITCbnE4DcHLNKB9lY+0/Nq+XpQh4k7GaauHultqqqmGtStsbDL AZ8OQZs8vi1dsYBsB0WPjl2uNiOfMHPss8VXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734126454; x=1734731254; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QTM8hNknJIeEkNf5MHdFtcyvDpU7J7d0jQYxJZBz0DE=; b=LTYFyjAkrV0VueEvQxvboUIfdskNAYWo/nrqhY/KL5nhMv72omnrZWO+P2nz0ToXUC E3XEHuP/DEe6MTI33V6Wwk2AEy4bwJPtNrRrmXZVEFoaTex4+tZeHfT4bskD6Vyhjjlc FqwgMpPsdnfbwGV10MON3VzACmEcJU5dz+gqRzqKVMzd9W5TwLPtjYDlAdJBHQIwKmnZ GxnA5tQOlGILRWi/4gZN0zS1LtsfXmFaIOOjldeXqNH2DY6dJ5XQpmhGmgzYfviSi3G1 tVW1qyuI75oVjV54SmHNJEVsiL+uYyUyTtiwMZqmRQOVyaysSgQ6poTbFguLYrp5no5a vx7w== X-Gm-Message-State: AOJu0YzRuNCf0oUD9wHFzi8WQyPYCXqH1i0oce2RokDtwRazTaByjLjx IjcfQepnsT5FHi4Kt8bdJVrbsYL8Cw6cTany4hlmZwICx+3Gd8m73FfHs7vbcSsA5eTYF06MjID uNgBc+RNUCaAl4a9oEl54VmdNr4lp3T6vzcQyj0GDXOLdNyijFQ== X-Gm-Gg: ASbGncuJV2FhX5S8mJqOTVVkIUD4JJYBOtuqz5iVJglYrrfzN3LlVxi98lXZHyFzhR5 zinGf6PXBJaJ4aCky7Ucki2o6MA4R6ilX1CE= X-Google-Smtp-Source: AGHT+IEtBGcCTlGPLbZPXBnuIZXjIr/C8L4bue8oVOy0T5uc8Re7sakF+Mfe1JoC1BrSJdplgAicr11YKaHdxP64BRE= X-Received: by 2002:a05:6102:1d:b0:4b2:49ff:9786 with SMTP id ada2fe7eead31-4b25db0b07fmr4689622137.17.1734126453827; Fri, 13 Dec 2024 13:47:33 -0800 (PST) MIME-Version: 1.0 References: <20241213180649.GW11590@mcvoy.com> In-Reply-To: From: Clem Cole Date: Fri, 13 Dec 2024 16:46:58 -0500 Message-ID: To: Marc Rochkind Content-Type: multipart/alternative; boundary="00000000000046c41806292dc7ad" Message-ID-Hash: 5A64356SHGMMTH4USWWPOAXCIRKY3OSH X-Message-ID-Hash: 5A64356SHGMMTH4USWWPOAXCIRKY3OSH X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The UNIX Historical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: SCCS roach motel List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000046c41806292dc7ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Marc and Larry As a satisfied user of SCCS (and later Bitkeeper), it's still my preferred choice. To this day, I have looked up directions to do simple things in Git that were so natural for me in SCCS. I don't think it's the old dog syndrome, either. SCCS was hardly perfect, but it solved a problem very well. Eric's sccs(1) front end for it from UCB cleaned up a few of the rough edges and experience taught us a little about care and feeding. Truth is I still use for small projects. It's easier to set up and it just protected me against myself. As a side note, it also exposed/demonstrated my real dislike for NFS early on when we started to see ZERO filled blocks in SCCS files (stateless just sucks). So thank you both. I have no idea how many times you saved my team and me time and bailed us out. =E1=90=A7 On Fri, Dec 13, 2024 at 1:33=E2=80=AFPM Marc Rochkind = wrote: > Larry, thanks for this. I had read some things you've written about the > weave before, but not with this level of detail. Sounds weird, but I didn= 't > really appreciate the implications of the weave even though I'm the guy w= ho > thought it up. I did understand the importance of not copying data if you > can reference it, which is a principle of database design (normal forms, > etc). > > In my paper, I can add a little more about the weave and its advantages. > Aside from this TUHS post, is there something I can put in the References > that people can find? > > Question: Is this right, that TeamWare was literally layered on top of > AT&T SCCS, but BitKeeper was layered on your implementation of SCCS? Or, > was it more complicated than that? > > Was your implementation of SCCS ever released by itself? > > Marc > > On Fri, Dec 13, 2024 at 11:06=E2=80=AFAM Larry McVoy wrote= : > >> On Fri, Dec 13, 2024 at 09:52:28AM -0700, Marc Rochkind wrote: >> > IEEE Transactions on Software Engineering has asked me to write a >> > retrospective on the influence of SCCS over the last 50 years, as my >> SCCS >> > paper was published in 1975. They consider it one of the most >> influential >> > papers from TSE's first decade. >> > >> > There's a funny quote from Ken Thompson that circulates from >> time-to-time: >> > >> > "SCCS, the source motel! Programs check in and never check out!" >> > >> > But nobody seems to know what it means exactly. As part of my research= , >> I >> > asked Ken what the quote meant, sunce I wanted to include it. He >> explained >> > that it refers to SCCS storing binary data in its repository file, >> > preventing UNIX text tools from operating on the file. >> > >> > Of course, this is only one of SCCS's many weaknesses. If you have >> anything >> > funny about any of the others, post it here. I already have all the >> boring >> > usual stuff (e.g., long-term locks, file-oriented, no merging). >> >> Warning, I know more about SCCS than the average person, I've >> reimplemented it from scratch and then built BitKeeper on top of an >> extended SCCS file format. So lots of info coming. Rick Smith and >> Wayne Scott know as much as I do, Rick knows more, he joined me and >> promptly started fixing my SCCS implementation. So far as I know, >> there is not a more knowledgable person that Rick when it comes to >> weave file formats. >> >> SCCS's strength is the weave format. It's largely not understood, even >> by other people working in source management. Here's the benefit of >> that weave (if people use it, which, other than BitKeeper, they don't, >> looking at you, Clearcase, you had a weave and didn't use it): SCCS can >> pass merge data by reference, everyone else copies the data. >> >> SCCS is a set based system. Each node has a revision number, like 1.5, >> but because SCCS, unlike RCS, limited the revisions to at most 4 fields, >> like 1.5.1.1, it is _impossible_ to build the history graph from the >> revisions, you can in simple graphs but as soon as you branch from a >> branch, all bets are off. >> >> The graph is built from what BitKeeper called serial numbers. Each node >> in the graph has at least 2 serials, one that names that node in the >> graph, and one that is the parent. >> >> So if I have a file with 5 revisions in straight line history, the >> internal stuff will look something like >> >> rev me parent >> 1.5 5 4 >> 1.4 4 3 >> 1.3 3 2 >> 1.2 2 1 >> 1.1 1 0 >> >> So what's the set? Pretty simple for straight line history, you walk >> the history from the rev that you want, adding the "me" serial and >> going to the parent, repeat until the parent is 0. >> >> Suppose you branch from rev 1.3. >> >> rev me parent >> 1.3.1.1 6 3 >> 1.5 5 4 >> 1.4 4 3 >> 1.3 3 2 >> ... >> >> See that 1.3.1.1 is me: 6 and parent: 3. So if I were building the set >> for 1.3.1.1, it becomes 6, then go to parent 3, 2, 1, skipping over 5 >> and 4. If you understand that, you are starting to understand the set >> and how it is constructed. >> >> Did you know you can have an argument in the revision history without >> adding anything to the data part? SCCS has the ability to include >> and/or exclude serials as part of a delta. Lets say Marc looked at >> my 1.5 and thought it was garbage. He can exclude it from the >> set like so: >> >> rev me parent include exclude >> 1.6 7 5 0 5 >> 1.3.1.1 6 3 >> 1.5 5 4 >> 1.4 4 3 >> 1.3 3 2 >> ... >> >> That doesn't change the data part of the file AT ALL, it's just saying >> Marc doesn't want anyone to see the 1.5 changes. >> >> To understand that, you need to know how SCCS checks out a file. And >> you need to know how the data is stored. Which is in a weave. RCS, >> and pretty much everything that followed it, doesn't use a weave at >> all. RCS stores the most recent version of the file as a complete >> copy of the checked out file. Then each delta working backwards up >> the trunk is a patch, what diff produces. >> >> Think about what that means for working on a branch. You have to start >> with the most recent version of the file, apply backward patches to go >> to earlier versions all the way back to the branch point, then apply >> forward patches to work your way to tip of the branch. Ask Dave Miller >> how pleasant it is to work on gcc on a branch. It's crazy slow and >> painful. >> >> So how does SCCS do it? Lets say the first version of a file is >> >> 1 >> 2 >> 3 >> 4 >> 5 >> >> The data portion of the history file will look like: >> >> ^AI 1 >> 1 >> 2 >> 3 >> 4 >> 5 >> ^AE 1 >> >> SCCS used ^A at the beginning of a line to mean "this is metadata for >> SCCS". ^AI is an insert, ^AD is a delete, and insert/delete are paired >> with a ^AE which means end. The number after is the serial. So that >> weave says "If serial 1 is in your set, everything after ^AI 1 is part >> of that set until you hit the matching ^AE 1. >> >> Lets say the 2nd version is >> >> 1 >> 2 >> serial 2 added this >> 3 >> 4 >> >> Notice that serial 2 deleted what was line 5. >> >> ^AI 1 >> 1 >> 2 >> ^AI 2 >> serial 2 added this >> ^AE 2 >> 3 >> 4 >> ^AD 2 >> 5 >> ^AE 2 >> ^AE 1 >> >> So now we can start to see how you walk the weave. If I'm trying to >> check out 1.1 aka serial 1, I build a set that has only '1' in the set. >> I hit the ^AI 1 see that I have 1 in my set, so I'm now in print mode, >> which means print each data line. I hit ^AI 2, that's not in my set, >> so I'm now in skip mode. And I skip the stuff inserted by serial 2. >> I see the ^AE 2 and I revert back to print mode. I get to ^AD 2, >> 2 is NOT in my set, so I stay in print mode. Etc. >> >> Let's make a branch, 1.1.1.1, with lots of data. >> >> 1 >> 2 >> 3 >> branch line 1 >> branch line 2 >> ... >> branch line 10000 >> 4 >> 5 >> >> ^AI 1 >> 1 >> 2 >> ^AI 2 >> serial 2 added this >> ^AE 2 >> 3 >> ^AI 3 >> branch line 1 >> branch line 2 >> ... >> branch line 10000 >> ^AE 3 >> 4 >> ^AD 2 >> 5 >> ^AE 2 >> ^AE 1 >> >> So if I checked out 1.1.1.1, the set is 1, 3, I walk the weave and I'll >> print anything inserted by either of those, delete anything deleted >> by those, skip anything inserted by anything not in the set, skip any >> deletes by anything not in the set. >> >> The delta table looks like this, notice I've added an author column: >> >> rev me parent include exclude author >> 1.1.1.1 3 1 lm >> 1.2 2 1 lm >> 1.1 1 0 lm >> >> If you followed all that, you can see how SCCS can merge by reference. >> Lets say Clem decides to merge my branch onto the trunk. The delta table >> will get a new entry: >> >> rev me parent include exclude author >> 1.3 4 2 3 clem >> 1.1.1.1 3 1 lm >> 1.2 2 1 lm >> 1.1 1 0 lm >> >> The weave DOES NOT CHANGE. That's the pass by reference. You do the 3 >> way >> merge, it will find the lines "3" and "5" as anchor points in both >> versions, >> so it is a simple insert with no new data added to the weave. >> >> Here's some magic that *everyone* else gets wrong when they pass by valu= e: >> In a system that passes by value (copies) the data, the merge done by cl= em >> would have an annotated listing like so: >> >> lm 1 >> lm 2 >> lm 3 >> clem branch line 1 >> clem branch line 2 >> clem ... >> clem branch line 10000 >> lm 4 >> lm 5 >> >> Since it copied the data, it looks like Clem wrote it but he didn't, he >> just automerged it. In SCCS/BitKeeper it would look like: >> >> lm 1 >> lm 2 >> lm 3 >> lm branch line 1 >> lm branch line 2 >> lm ... >> lm branch line 10000 >> lm 4 >> lm 5 >> >> which is correct, all of those lines were authored by one person. The >> only >> time the merger should show up as an author is if there was a conflict, >> however the merger resolved that conflict is new work and should be >> authored by the merger. >> >> What BitKeeper did, that was a profound step forward, was make the idea >> of a repository a formal thing and introduced the concept of changesets >> that keeps track of all this stuff at the repository level. So it does >> all this stuff at the file level but you don't have to do that low level >> work. You could think of SCCS as assembly and BitKeeper as more like C, >> it upleveled things to the point that humans can manage the repository >> easily. >> >> Whew. That's a butt load of info. Perhaps better for COFF? Any >> questions? It should be obvious that I *love* SCCS, it's a dramatically >> better file format than a patch based one, you can get *any* version of >> the file in constant time, authorship can be preserved across versions, >> it's pretty brilliant and I consider myself blessed to be posting this >> in response to SCCS's creator. Hats off to Marc. And big boo, hiss, >> to the RCS guy, who got a PhD for RCS (give me a break) and did the >> world a huge disservice by bad mouthing SCCS so he could promote RCS. >> >> --lm >> > > > -- > *My new email address is mrochkind@gmail.com * > --00000000000046c41806292dc7ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Marc and Larry

As a satisfied= user of SCCS (and later Bitkeeper), it's still my preferred choice. To= this day, I have looked up directions to do simple things in Git that were= so natural for me in SCCS. I don't think it's the old dog syndrome= ,=C2=A0either. SCCS was hardly perfect, but it solved a problem very well.= =C2=A0 =C2=A0Eric's sccs(1) front end for it from UCB cleaned up a few = of the rough edges and experience taught us a little about care and feeding= .=C2=A0 Truth is I still use for small projects.=C2=A0 It's easier to s= et up and it just protected=C2=A0me against myself.

As= a=C2=A0side note, it=C2=A0also exposed/demonstrated my real dislike for NF= S early on when we started to see ZERO filled blocks in SCCS files (statele= ss just sucks).

So thank you both. I have no idea how = many times you saved my team and me time and bailed us out.
3D""=E1=90=A7
On Fri, Dec 13, 2024 at 1:33=E2=80= =AFPM Marc Rochkind <mrochkind@gm= ail.com> wrote:
Larry, thanks for this. I had read some things= you've written about the weave before, but not with this level of deta= il. Sounds weird, but I didn't really appreciate the implications of th= e weave even though I'm the guy who thought it up. I did understand the= importance of not copying data if you can reference it, which is a princip= le of database design (normal forms, etc).

In my p= aper, I=C2=A0can add a little more about the weave and its advantages. Asid= e from this TUHS post, is there something I can put in the References that = people can find?

Question: Is this right, that Tea= mWare was literally layered on top of AT&T SCCS, but BitKeeper was laye= red on your implementation of SCCS? Or, was it more complicated than that?<= /div>

Was your implementation of SCCS ever released by i= tself?

Marc

On Fri, Dec 13, 2024 at 11:06=E2=80=AFA= M Larry McVoy <lm@mcvo= y.com> wrote:
On Fri, Dec 13, 2024 at 09:52:28AM -0700, Marc Rochkind wrote:
> IEEE Transactions on Software Engineering has asked me to write a
> retrospective on the influence of SCCS over the last 50 years, as my S= CCS
> paper was published in 1975. They consider it one of the most influent= ial
> papers from TSE's first decade.
>
> There's a funny quote from Ken Thompson that circulates from time-= to-time:
>
> "SCCS, the source motel! Programs check in and never check out!&q= uot;
>
> But nobody seems to know what it means exactly. As part of my research= , I
> asked Ken what the quote meant, sunce I wanted to include it. He expla= ined
> that it refers to SCCS storing binary data in its repository file,
> preventing UNIX text tools from operating on the file.
>
> Of course, this is only one of SCCS's many weaknesses. If you have= anything
> funny about any of the others, post it here. I already have all the bo= ring
> usual stuff (e.g., long-term locks, file-oriented, no merging).

Warning, I know more about SCCS than the average person, I've
reimplemented it from scratch and then built BitKeeper on top of an
extended SCCS file format.=C2=A0 So lots of info coming.=C2=A0 Rick Smith a= nd
Wayne Scott know as much as I do, Rick knows more, he joined me and
promptly started fixing my SCCS implementation.=C2=A0 So far as I know, there is not a more knowledgable person that Rick when it comes to
weave file formats.

SCCS's strength is the weave format.=C2=A0 It's largely not underst= ood, even
by other people working in source management.=C2=A0 Here's the benefit = of
that weave (if people use it, which, other than BitKeeper, they don't,<= br> looking at you, Clearcase, you had a weave and didn't use it): SCCS can=
pass merge data by reference, everyone else copies the data.

SCCS is a set based system.=C2=A0 =C2=A0Each node has a revision number, li= ke 1.5,
but because SCCS, unlike RCS, limited the revisions to at most 4 fields, like 1.5.1.1, it is _impossible_ to build the history graph from the
revisions, you can in simple graphs but as soon as you branch from a
branch, all bets are off.

The graph is built from what BitKeeper called serial numbers.=C2=A0 Each no= de
in the graph has at least 2 serials, one that names that node in the
graph, and one that is the parent.

So if I have a file with 5 revisions in straight line history, the
internal stuff will look something like

rev=C2=A0 =C2=A0 =C2=A0me=C2=A0 =C2=A0 =C2=A0 parent
1.5=C2=A0 =C2=A0 =C2=A05=C2=A0 =C2=A0 =C2=A0 =C2=A04
1.4=C2=A0 =C2=A0 =C2=A04=C2=A0 =C2=A0 =C2=A0 =C2=A03
1.3=C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A0 =C2=A0 =C2=A02
1.2=C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A01
1.1=C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A00

So what's the set?=C2=A0 Pretty simple for straight line history, you w= alk
the history from the rev that you want, adding the "me" serial an= d
going to the parent, repeat until the parent is 0.

Suppose you branch from rev 1.3.

rev=C2=A0 =C2=A0 =C2=A0me=C2=A0 =C2=A0 =C2=A0 parent
1.3.1.1 6=C2=A0 =C2=A0 =C2=A0 =C2=A03
1.5=C2=A0 =C2=A0 =C2=A05=C2=A0 =C2=A0 =C2=A0 =C2=A04
1.4=C2=A0 =C2=A0 =C2=A04=C2=A0 =C2=A0 =C2=A0 =C2=A03
1.3=C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A0 =C2=A0 =C2=A02
...

See that 1.3.1.1 is me: 6 and parent: 3.=C2=A0 So if I were building the se= t
for 1.3.1.1, it becomes 6, then go to parent 3, 2, 1, skipping over 5
and 4.=C2=A0 If you understand that, you are starting to understand the set=
and how it is constructed.

Did you know you can have an argument in the revision history without
adding anything to the data part?=C2=A0 SCCS has the ability to include and/or exclude serials as part of a delta.=C2=A0 Lets say Marc looked at my 1.5 and thought it was garbage.=C2=A0 He can exclude it from the
set like so:

rev=C2=A0 =C2=A0 =C2=A0me=C2=A0 =C2=A0 =C2=A0 parent=C2=A0 include exclude<= br> 1.6=C2=A0 =C2=A0 =C2=A07=C2=A0 =C2=A0 =C2=A0 =C2=A05=C2=A0 =C2=A0 =C2=A0 = =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A05
1.3.1.1 6=C2=A0 =C2=A0 =C2=A0 =C2=A03
1.5=C2=A0 =C2=A0 =C2=A05=C2=A0 =C2=A0 =C2=A0 =C2=A04
1.4=C2=A0 =C2=A0 =C2=A04=C2=A0 =C2=A0 =C2=A0 =C2=A03
1.3=C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A0 =C2=A0 =C2=A02
...

That doesn't change the data part of the file AT ALL, it's just say= ing
Marc doesn't want anyone to see the 1.5 changes.

To understand that, you need to know how SCCS checks out a file.=C2=A0 And<= br> you need to know how the data is stored.=C2=A0 Which is in a weave.=C2=A0 R= CS,
and pretty much everything that followed it, doesn't use a weave at
all.=C2=A0 RCS stores the most recent version of the file as a complete copy of the checked out file.=C2=A0 Then each delta working backwards up the trunk is a patch, what diff produces.

Think about what that means for working on a branch.=C2=A0 You have to star= t
with the most recent version of the file, apply backward patches to go
to earlier versions all the way back to the branch point, then apply
forward patches to work your way to tip of the branch.=C2=A0 Ask Dave Mille= r
how pleasant it is to work on gcc on a branch.=C2=A0 It's crazy slow an= d
painful.

So how does SCCS do it?=C2=A0 Lets say the first version of a file is

1
2
3
4
5

The data portion of the history file will look like:

^AI 1
1
2
3
4
5
^AE 1

SCCS used ^A at the beginning of a line to mean "this is metadata for<= br> SCCS".=C2=A0 ^AI is an insert, ^AD is a delete, and insert/delete are = paired
with a ^AE which means end.=C2=A0 The number after is the serial.=C2=A0 So = that
weave says "If serial 1 is in your set, everything after ^AI 1 is part=
of that set until you hit the matching ^AE 1.

Lets say the 2nd version is

1
2
serial 2 added this
3
4

Notice that serial 2 deleted what was line 5.

^AI 1
1
2
^AI 2
serial 2 added this
^AE 2
3
4
^AD 2
5
^AE 2
^AE 1

So now we can start to see how you walk the weave.=C2=A0 If I'm trying = to
check out 1.1 aka serial 1, I build a set that has only '1' in the = set.
I hit the ^AI 1 see that I have 1 in my set, so I'm now in print mode,<= br> which means print each data line.=C2=A0 I hit ^AI 2, that's not in my s= et,
so I'm now in skip mode.=C2=A0 And I skip the stuff inserted by serial = 2.
I see the ^AE 2 and I revert back to print mode.=C2=A0 I get to ^AD 2,
2 is NOT in my set, so I stay in print mode.=C2=A0 Etc.

Let's make a branch, 1.1.1.1, with lots of data.

1
2
3
branch line 1
branch line 2
...
branch line 10000
4
5

^AI 1
1
2
^AI 2
serial 2 added this
^AE 2
3
^AI 3
branch line 1
branch line 2
...
branch line 10000
^AE 3
4
^AD 2
5
^AE 2
^AE 1

So if I checked out 1.1.1.1, the set is 1, 3, I walk the weave and I'll=
print anything inserted by either of those, delete anything deleted
by those, skip anything inserted by anything not in the set, skip any
deletes by anything not in the set.

The delta table looks like this, notice I've added an author column:
rev=C2=A0 =C2=A0 =C2=A0me=C2=A0 =C2=A0 =C2=A0 parent=C2=A0 include exclude = author
1.1.1.1 3=C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lm
1.2=C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lm
1.1=C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lm

If you followed all that, you can see how SCCS can merge by reference.
Lets say Clem decides to merge my branch onto the trunk. The delta table will get a new entry:

rev=C2=A0 =C2=A0 =C2=A0me=C2=A0 =C2=A0 =C2=A0 parent=C2=A0 include exclude = author
1.3=C2=A0 =C2=A0 =C2=A04=C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 = =C2=A03=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clem
1.1.1.1 3=C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lm
1.2=C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lm
1.1=C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lm

The weave DOES NOT CHANGE.=C2=A0 That's the pass by reference.=C2=A0 Yo= u do the 3 way
merge, it will find the lines "3" and "5" as anchor poi= nts in both versions,
so it is a simple insert with no new data added to the weave.

Here's some magic that *everyone* else gets wrong when they pass by val= ue:
In a system that passes by value (copies) the data, the merge done by clem<= br> would have an annotated listing like so:

lm=C2=A0 =C2=A0 =C2=A0 1
lm=C2=A0 =C2=A0 =C2=A0 2
lm=C2=A0 =C2=A0 =C2=A0 3
clem=C2=A0 =C2=A0 branch line 1
clem=C2=A0 =C2=A0 branch line 2
clem=C2=A0 =C2=A0 ...
clem=C2=A0 =C2=A0 branch line 10000
lm=C2=A0 =C2=A0 =C2=A0 4
lm=C2=A0 =C2=A0 =C2=A0 5

Since it copied the data, it looks like Clem wrote it but he didn't, he=
just automerged it.=C2=A0 In SCCS/BitKeeper it would look like:

lm=C2=A0 =C2=A0 =C2=A0 1
lm=C2=A0 =C2=A0 =C2=A0 2
lm=C2=A0 =C2=A0 =C2=A0 3
lm=C2=A0 =C2=A0 =C2=A0 branch line 1
lm=C2=A0 =C2=A0 =C2=A0 branch line 2
lm=C2=A0 =C2=A0 =C2=A0 ...
lm=C2=A0 =C2=A0 =C2=A0 branch line 10000
lm=C2=A0 =C2=A0 =C2=A0 4
lm=C2=A0 =C2=A0 =C2=A0 5

which is correct, all of those lines were authored by one person.=C2=A0 The= only
time the merger should show up as an author is if there was a conflict, however the merger resolved that conflict is new work and should be
authored by the merger.

What BitKeeper did, that was a profound step forward, was make the idea
of a repository a formal thing and introduced the concept of changesets
that keeps track of all this stuff at the repository level.=C2=A0 So it doe= s
all this stuff at the file level but you don't have to do that low leve= l
work.=C2=A0 You could think of SCCS as assembly and BitKeeper as more like = C,
it upleveled things to the point that humans can manage the repository
easily.

Whew.=C2=A0 That's a butt load of info.=C2=A0 Perhaps better for COFF?= =C2=A0 Any
questions?=C2=A0 It should be obvious that I *love* SCCS, it's a dramat= ically
better file format than a patch based one, you can get *any* version of
the file in constant time, authorship can be preserved across versions,
it's pretty brilliant and I consider myself blessed to be posting this<= br> in response to SCCS's creator.=C2=A0 Hats off to Marc.=C2=A0 And big bo= o, hiss,
to the RCS guy, who got a PhD for RCS (give me a break) and did the
world a huge disservice by bad mouthing SCCS so he could promote RCS.

--lm


--
My new email address is mrochkind@gmail.com
<= /div>
--00000000000046c41806292dc7ad--