9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dan Cross <crossd@gmail.com>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] VCS on Plan9
Date: Thu, 18 Apr 2024 16:41:50 -0400	[thread overview]
Message-ID: <CAEoi9W6t636YRSu9nPCbvuFiNVMK=UPi_e4BKRcUyfZZddmCiQ@mail.gmail.com> (raw)
In-Reply-To: <4AB7C637-0E7D-492E-AA3A-BEAA980B22BB@iitbombay.org>

On Thu, Apr 18, 2024 at 4:27 PM Bakul Shah via 9fans <9fans@9fans.net> wrote:
> Did anyone try to port sccs to plan9?

Interesting question; I suspect not.  The only reason to have done so
would have been to inspect source repositories created outside of plan
9, in which case it likely would have been more natural to do so via
Unix (at least for the repositories I can think of that would have
been adjacent).

Culturally, there was a feeling that source revision a la RCS, SCCS,
etc, were unnecessary because the dump filesystem gave you snapshots
already. Moreover, those were automatic and covered more than one file
at a time; RCS/SCCS required some discipline in that one had to
remember to check in a new revision. And as Paul said, the idea of an
atomic, multi-file changeset was revolutionary at the time.

The downside of the filesystem approach for maintaining history is
two-fold: 1) granularity. Typically the dump is only generated once a
day, but often one would rather commit more frequently (or perhaps
less so...) than that. 2) context. As it turns out, the ability to
associate a changeset with a well-written commit message is very
valuable. I have lost count of the number of times I've asked, "what
was going on when _this_ code was written?" Having that directly
available from the source repository is incredibly powerful.

Thankfully, I doubt anyone is using the old patch mechanism anymore.
Git and Jujitsu are, frankly, superior.

        - Dan C.

> On Apr 18, 2024, at 9:11 AM, Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>
> The Bell Labs approach to source control was, I'm, weak.  It relied on snapshots of the tree and out-of-band communication.  Don't forget how small and tight-knit that development team was, and how valuable perfect historic snapshots were.
>
> Add that 40 years ago source code revision control systems were incredibly primitive.  The idea of an atomic change set (in Unix land at least) was revolutionary in the early 90s.
>
> This is one place where 35 years of evolution in software practices has very much improved.
>
> Paul
>
> On Thu, Apr 18, 2024, 8:55 a.m. certanan via 9fans <9fans@9fans.net> wrote:
>> 
>> Hi,
>> 
>> is there any more "organic/natural" way to do source control on today's Plan9 (9front specifically), other than Ori's Git?
>> 
>> In other words, how (if at all) did people at Bell Labs and the community alike originally manage their contributions in a way that would allow them to create patches without much hassle?
>> 
>> Was it as simple as backing a source tree up, making some changes, and then comparing the two? Venti? Replica?
>> 
>> tom
>
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-Mec07348f737f68bed8fea253
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

  reply	other threads:[~2024-04-18 20:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18 15:54 certanan via 9fans
2024-04-18 16:02 ` Jacob Moody
2024-04-18 16:05   ` certanan via 9fans
2024-04-18 16:11 ` Paul Lalonde
2024-04-18 20:26   ` Bakul Shah via 9fans
2024-04-18 20:41     ` Dan Cross [this message]
2024-04-18 21:00       ` Steve simon
2024-04-18 21:40         ` Dan Cross
2024-04-19  4:09           ` ori
2024-04-19 14:01             ` Dan Cross
2024-04-18 21:48       ` Shawn Rutledge
2024-04-18 23:17         ` Bakul Shah via 9fans
2024-04-18 23:52           ` Dan Cross
2024-04-19  0:09         ` Jacob Moody
2024-04-18 23:15       ` Bakul Shah via 9fans
2024-04-20  8:30       ` Giacomo Tesio
2024-04-20 19:11         ` Dan Cross
2024-04-18 16:34 ` cinap_lenrek
2024-04-18 16:47   ` Dave Eckhardt
2024-04-19  9:07     ` Edouard Klein
2024-04-19  9:34       ` Stuart Morrow
2024-04-18 20:08 ` Ori Bernstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEoi9W6t636YRSu9nPCbvuFiNVMK=UPi_e4BKRcUyfZZddmCiQ@mail.gmail.com' \
    --to=crossd@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).