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=2.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MALFORMED_FREEMAIL,MISSING_HEADERS autolearn=no autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id EE7AA2A6D9 for ; Fri, 13 Dec 2024 19:39:28 +0100 (CET) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 4753242724; Sat, 14 Dec 2024 04:39:24 +1000 (AEST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by minnie.tuhs.org (Postfix) with ESMTPS id 64EC742722 for ; Sat, 14 Dec 2024 04:39:18 +1000 (AEST) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3862f32a33eso1016723f8f.3 for ; Fri, 13 Dec 2024 10:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734115156; x=1734719956; darn=tuhs.org; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=YuImRtMmOT06zVFn2aLv0XFPqbasjPDH0gl8e7g7Yho=; b=BI6eVEi2i6uIt+mzFYAGbfrCatFEWseiB7ujGTG4ipWH4Ai/bU00W36wWFN69mhAAq ehGQPu9dxU5re2p6Ysx9mE0GbNJ35vaUEqUr7FngNrItAA4rSPPhQpZggiyRX/3t890M mk5dvztvX660PqGrbH0d78z9S7+kr/qvrQ/HFVY4KrIVHNUfm5I51B8dw1kIPJmBkr0L 8abFUADdmy7kyJZFUFBlHsJKDD/SqT4oCpJb5qjVpbZ0sEyYDguCPIxn3CYnhPJv4PM1 D/ZZGeg1K4MsvoK+pz4G7bqTK5TnffpeAoBU3NMM2iWvUfmqZvlYZEG/ZwPENg+YvYjo gDDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734115156; x=1734719956; h=cc: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=YuImRtMmOT06zVFn2aLv0XFPqbasjPDH0gl8e7g7Yho=; b=GnUjU6G4Lsz+W8hEFjzUKMrmdBTs8gwHyP0LdQmidVjKNjqNrq8s5os86QwkJbjLSs x3ao9La9jMo6+3vAah1YvZVM/V1OvI3SRL0DvCJfwr9WuhiSUTB4jIp3Aimi9fmzBQnq +bBqZ65dbTBQgwwj9d3FHixhMug39W0sqD/ybpgkdwjLMkNIEWYUneve8MtH76eLNfSQ mYAb+aCOX3yqIn2EUuxWNtBj5qjM7GpXT3/Z30rcd/RgmEinAxVhpD0psS+mBDx7r033 b66RVlagGXW1nAUQtgleXOIIiRZHO9u6MmrmZ0S4QMwU5Qs7ufIQOuGqM+lLIFzok1RZ ZKzw== X-Gm-Message-State: AOJu0YzofOLHtYZYTyurec9P0RtKLxEcRCcAkb03RotwcYBqI3Mk9GLD OG0CEQ16X21P/0mSbZCIoyu2QV4CZm1NVJzEIpJUbq8oaocVaVn+lfHbBTvwdnJirDJpNPKG5rD CNBr0407iAi9IGDUupcGGnz039ZV5pAc= X-Gm-Gg: ASbGncvG89LxpvetwL8y0GDYl0EqMxo2SPPU18EN0IaYoCKyx365f1IYjU1Fc/5Uf/T u8n9EIstlZZe9W53d2iTRoexr0pT8ivq6AD8G X-Google-Smtp-Source: AGHT+IFvQlIHYoYc2P8aQlB6clBBkCmC+6mH0zNSGsGo+Qru5qh3nt/XU/kDfEsCnDylkLE3EW9L57EHtXosfpzA8mY= X-Received: by 2002:a05:6000:1787:b0:386:3db6:2775 with SMTP id ffacd0b85a97d-3888e0ae59cmr3534558f8f.25.1734115155763; Fri, 13 Dec 2024 10:39:15 -0800 (PST) MIME-Version: 1.0 References: <20241213180649.GW11590@mcvoy.com> In-Reply-To: From: Marc Rochkind Date: Fri, 13 Dec 2024 11:39:03 -0700 Message-ID: Cc: The UNIX Historical Society Content-Type: multipart/alternative; boundary="000000000000dbe98206292b2592" Message-ID-Hash: B6DCTVPPMD4OYSP7LBSD2ANRLYLU3I3I X-Message-ID-Hash: B6DCTVPPMD4OYSP7LBSD2ANRLYLU3I3I X-MailFrom: mrochkind@gmail.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 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: --000000000000dbe98206292b2592 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Larry, I found this: https://www.bitkeeper.org/src-notes/SCCSWEAVE.html A good reference? Marc On Fri, Dec 13, 2024 at 11:32=E2=80=AFAM 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 * > --=20 *My new email address is mrochkind@gmail.com * --000000000000dbe98206292b2592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Larry, I found this:


A good reference?

Marc

On Fri, Dec 13, 2024 at 1= 1:32=E2=80=AFAM Marc Rochkind <mr= ochkind@gmail.com> wrote:
Larry, thanks for this. I had read s= ome things you've written about the weave before, but not with this lev= el of detail. Sounds weird, but I didn't really appreciate the implicat= ions of the weave even though I'm the guy who thought it up. I did unde= rstand 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=C2=A0can add a little more about the weave and its advant= ages. Aside from this TUHS post, is there something I can put in the Refere= nces that people can find?

Question: Is this right= , that TeamWare was literally layered on top of AT&T SCCS, but BitKeepe= r was layered on your implementation of SCCS? Or, was it more complicated t= han that?

Was your implementation of SCCS ever rel= eased by itself?

Marc

On Fri, Dec 13, 2024 at 11:06= =E2=80=AFAM Larry McVoy <lm@mcvoy.com> wrote:
On Fri, Dec 13, 2024 at 09:52:28AM -0700, Marc Rochkind wrot= e:
> 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>


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