[9fans] VCS on Plan9

[9fans] VCS on Plan9

[certanan via 9fans]

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
Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M3ad4cc51ed9aebb728fe83f8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Jacob Moody]

On 4/18/24 10:54, certanan via 9fans 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?

Perhaps worth mentioning that before git 9front used mecurial for VCS, but I don't think that answers your question.
From what I understand folks used to make diffs against the last release. There was also some use of replica as you eluded to.


Thanks,
moody


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

Re: [9fans] VCS on Plan9

[certanan via 9fans]

> From what I understand folks used to make diffs against the last release. There was also some use of replica as you eluded to.

That answers my question. Thanks.


tom

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

Re: [9fans] VCS on Plan9

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

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
Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M1b6d6751f6d830d2a70a696f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2713 bytes --]

Re: [9fans] VCS on Plan9

[cinap_lenrek]

One thing i did was sometimes to create a skeletron directory
tree and bind *before* each single directory in /sys/src/9.

when i needed to modify a file, you copy it in your "overlay"
tree.

not exactly version control, but a primitive way to prepare
a change.

--
cinap

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

Re: [9fans] VCS on Plan9

[Dave Eckhardt]

> One thing i did was sometimes to create a skeletron directory
> tree and bind *before* each single directory in /sys/src/9.
>
> when i needed to modify a file, you copy it in your "overlay"
> tree.

https://9p.io/wiki/plan9/divergefs/

Dave Eckhardt

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

Re: [9fans] VCS on Plan9

[Ori Bernstein]

On Thu, 18 Apr 2024 15:54:07 +0000
"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?

on today's plan 9? no.

> 
> 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?

on labs plan 9: https://9p.io/magic/man2html/1/patch

I dont think anyone is submitting patches with this any more.

> 
> Was it as simple as backing a source tree up, making some changes, and then comparing the two? Venti? Replica?
> 
> tom


-- 
Ori Bernstein <ori@eigenstate.org>

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

Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

Did anyone try to port sccs to plan9?

> 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 <mailto: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 <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M1b6d6751f6d830d2a70a696f>

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

[-- Attachment #2: Type: text/html, Size: 3354 bytes --]

Re: [9fans] VCS on Plan9

[Dan Cross]

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

Re: [9fans] VCS on Plan9

[Steve simon]

re: VCS -vs-dump

I always planned to add code to fossil to allow members of (say) the 'dump' group to trigger fa fossil to venti dump at arbitrary times.
If with this it would be trivial to have a 'release' rc script which could save a log message and trigger a dump.

I know this is not really a VCS but the ability to get back to an atomic set of files representing a release would help a lot IMHO.

-Steve

> On 18 Apr 2024, at 21:41, Dan Cross <crossd@gmail.com> wrote:
> 
> Jujitsu



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

Re: [9fans] VCS on Plan9

[Dan Cross]

On Thu, Apr 18, 2024 at 5:01 PM Steve simon <steve@quintile.net> wrote:
> re: VCS -vs-dump
>
> I always planned to add code to fossil to allow members of (say) the 'dump' group to trigger fa fossil to venti dump at arbitrary times.
> If with this it would be trivial to have a 'release' rc script which could save a log message and trigger a dump.

Correct me if I'm wrong, but this is just an `echo` into fossilcons,
isn't it? `fsys main snap -a` or something like it?

> I know this is not really a VCS but the ability to get back to an atomic set of files representing a release would help a lot IMHO.

I could see the utility in that, but at this point, a repo in some
modern VCS that contained the source combined with a snapshot of the
release contents (containing binaries and so on) would be better,
IMHO.

Ironically, this came full circle for me a decade or so ago at Google.
I was explaining Venti to someone and they said, "why did they write
that? Why not just write to git?" I had to explain that Venti predated
`git` by several years. Kids these days!

        - Dan C.

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

Re: [9fans] VCS on Plan9

[Shawn Rutledge]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

> On Apr 18, 2024, at 1:41 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> Git and Jujitsu are, frankly, superior.

Aha, I had never heard of Jujutsu until now; you mean https://martinvonz.github.io/jj/ right?  Monitoring file changes and treating changes to the working copy as an implicit work-in-progress commit sounds like a good idea, good for filesystem-integrated revision control.  In my usual markdown editor that I use for notes (https://github.com/ec1oud/nettebook) I’m planning to add UI for making git commits.  I suppose prompting for a customized commit message would still be a good idea, but otherwise getting commits automatically without needing to add that as an application feature or remembering to do it on the command line might be a good feature.

Interesting that it's Rust.  Just another reason to eventually have Rust on Plan 9…

For prose purposes (especially auto-wrapped Markdown) it bothers me that git diff mainly does line diffs.  So I’ve been trying to find an efficient algorithm for word diffs.  (Yes there is git diff --word-diff, but for an application to show this graphically, I’m not a big fan of running a separate process for it.  And the output needs parsing anyway.)  It seems a common technique is the facepalm one: turn every space into a newline and then do line diffs.  But there’s another old Bell project: https://github.com/HaikuArchives/Spiff.git  It’s kindof ugly code and with lots of comments about how inefficient it is, but at least it starts by tokenizing and then working with word lists in memory instead of character substitution.  So I’m working on a fork to try to turn it into a library (will see if that’s worthwhile or just leads to a sufficient understanding of the algorithm that I’d rather start over).  But this could also be the sort of thing Jujutsu could improve upon, I suppose.


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

[-- Attachment #2: Type: text/html, Size: 3859 bytes --]

Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

On Apr 18, 2024, at 1:41 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> 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.

Readers here may be interested in our experience (circa 1982!)

At Fortune Systems, in 1982, Dave Yost come up with "cloned
tree" system for source code control. The idea was, each
developer gets their own src tree where all the files are
initally hard linked with the mastr tree (& are readonly). We
modified vi to always save the old file foo as ,foo and write
out a new file foo. [Note that the Rand editor e which many
of us used already did this.] This makes it easy to see that
files with link count == 1 are modified locally.  When some
feature / bugix is complete, someone would manually "commit"
changes to the "master" branch using diff to review them.
Dave wrote a paper about this called "A Rich Man's SCCS" in
Usenix Summer 1985.

Looking back, we had some (fuzzy) idea of a change set. But
we didn't have a way to keep a log of what changed and why.
And we didn't automate "commit". We did have a way of naming
top level trees ("frozen" ones by the date of the latest
modified file, development ones by the version we were
working on + developer name). We also modified tar to allow
saving and restoring a set of trees (recreating links for
identical files).
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-Me7d866a5dbc8db8e84dd93be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Apr 18, 2024, at 2:48 PM, Shawn Rutledge <lists@ecloud.org> wrote:
> 
> Just another reason to eventually have Rust on Plan 9…

Yeah. Compiles are too damn fast; no time to make masala chai :-)


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

[-- Attachment #2: Type: text/html, Size: 1595 bytes --]

Re: [9fans] VCS on Plan9

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Thu, Apr 18, 2024, 7:18 PM Bakul Shah via 9fans <9fans@9fans.net> wrote:

> On Apr 18, 2024, at 2:48 PM, Shawn Rutledge <lists@ecloud.org> wrote:
>
>
> Just another reason to eventually have Rust on Plan 9…
>
>
> Yeah. Compiles are too damn fast; no time to make masala chai :-)
>

Arrey yaar, miri vo ki bahoat problem hain.

        - Dan C.


> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M56e1b18e4d67c6281934993d>
>

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

[-- Attachment #2: Type: text/html, Size: 2141 bytes --]

Re: [9fans] VCS on Plan9

[Jacob Moody]

On 4/18/24 16:48, Shawn Rutledge wrote:
> Interesting that it's Rust.  Just another reason to eventually have Rust on Plan 9…
Has anyone done any work on this? I know someone technically got stuff running using a
webasm intermediate, but I am curious if anyone has scoped out what it would look like
to do a proper port.

Cross compiling from some linux to a plan 9 a.out and bootstrapping that way seems to be the most likely.


Thanks,
moody


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

Re: [9fans] VCS on Plan9

[ori]

Quoth Dan Cross <crossd@gmail.com>:
> 
> Correct me if I'm wrong, but this is just an `echo` into fossilcons,
> isn't it? `fsys main snap -a` or something like it?

it would be if being able to write to fossilcons
didn't imply being able to do a lot more than
creating a new snapshot.



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

Re: [9fans] VCS on Plan9

[Edouard Klein]

I love it when I discover that something down on my todo-list has
already been done, better than I would have, by someone else :)

Very neat tool, I'll be using it soon.
Dave Eckhardt <davide+p9@cs.cmu.edu> writes:

>> One thing i did was sometimes to create a skeletron directory
>> tree and bind *before* each single directory in /sys/src/9.
>>
>> when i needed to modify a file, you copy it in your "overlay"
>> tree.
> 
> https://9p.io/wiki/plan9/divergefs/
> 
> Dave Eckhardt

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

Re: [9fans] VCS on Plan9

[Stuart Morrow]

On Fri, 19 Apr 2024 at 10:09, Edouard Klein <edou@rdklein.fr> wrote:
> I love it when I discover that something down on my todo-list has
> already been done, [ ...
> ... ]
> > https://9p.io/wiki/plan9/divergefs/

It's been done *twice*: https://git.sr.ht/~kvik/unionfs

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

Re: [9fans] VCS on Plan9

[Dan Cross]

On Fri, Apr 19, 2024 at 12:10 AM <ori@eigenstate.org> wrote:
> Quoth Dan Cross <crossd@gmail.com>:
> > Correct me if I'm wrong, but this is just an `echo` into fossilcons,
> > isn't it? `fsys main snap -a` or something like it?
>
> it would be if being able to write to fossilcons
> didn't imply being able to do a lot more than
> creating a new snapshot.

Fair point. But it would be pretty simple to write a small proxy
service that wrapped that, and only exposed something that let an
authorized user trigger writing the `snap` command into `fossilcons`
on one's behalf. The point is, the raw tools to do what Steve proposed
mostly already exist; wiring them up shouldn't require any changes to
fossil itself.

This is all rather far afield from the issue of revision control,
though. Getting back to that, a true VCS and the sort of backup
facility offered by fossil+venti (and other similar things, such as
the work you've done on filesystems) are mostly orthogonal.

        - Dan C.

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

Re: [9fans] VCS on Plan9

[Giacomo Tesio]

Hi 9fans

Il 18 Aprile 2024 22:41:50 CEST, Dan Cross <crossd@gmail.com> ha scritto:
> 
> Git and Jujitsu are, frankly, superior

out of curiosity, to your knowedge, did anyone ever tried to port fossil scm
to Plan9 or 9front (even through ape)?

<https://fossil-scm.org/home/doc/trunk/www/index.wiki>

Also (tangential) did anybody tried to port Tiny-CC?


Giacomo

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

Re: [9fans] VCS on Plan9

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Sat, Apr 20, 2024 at 4:31 AM Giacomo Tesio <giacomo@tesio.it> wrote:

> Hi 9fans
>
> Il 18 Aprile 2024 22:41:50 CEST, Dan Cross <crossd@gmail.com> ha scritto:
> >
> > Git and Jujitsu are, frankly, superior
>
> out of curiosity, to your knowedge, did anyone ever tried to port fossil
> scm
> to Plan9 or 9front (even through ape)?
>
> <https://fossil-scm.org/home/doc/trunk/www/index.wiki>


Not to my knowledge, no.

Also (tangential) did anybody tried to port Tiny-CC?


No idea, sorry.

        - Dan C.

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

[-- Attachment #2: Type: text/html, Size: 2070 bytes --]