Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

On Apr 18, 2024, at 2:48 PM, Shawn Rutledge  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

Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

On Apr 18, 2024, at 1:41 PM, Dan Cross  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]

Did anyone try to port sccs to plan9?

> On Apr 18, 2024, at 9:11 AM, Paul Lalonde  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-M65f0bf5f4f88547e7f42ac54
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Bakul Shah via 9fans]

On Apr 15, 2024, at 1:50 PM, Charles Forsyth  wrote:
> 
> And, if I hear about it being
> “declarative” as a virtue, I point to the 81,000+ lines (and
> growing) of YAML, that I defy any one human to comprehend.
> 
> You might find help in culang.org

Not sure how much the Cue language will help when the
underlying model of Kubernetes is quite complex (pods,
containers, deployments, nodes, schedulers, controllers,
clusters, services, load balancing, tasks, kubelets,
kube-proxies, api-servers, multi-tenancy, replicas,
namespaces and so on). May be all you can do is push this
complexity around but not conquer it.

In any new design, at the start you often overbuild
because you don't quite know what will work but soon you
have to sense what is scaffolding and can be removed vs
what is essential and must be left in.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M532d92757e5a02a419f67eac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Bakul Shah via 9fans]

Faster for any command that operates on dir trees such as diff, du, rm, tar.When I first looked at plan9, I was a bit surprised its open *didn’t* workthis way! May be because of this earlier thread on comp.unix.wizardshttps://groups.google.com/g/comp.unix.wizards/c/i8vapj9BAqs/m/FlNUK705I0UJ (which has nothing to do with plan9 but people explored some researchy ideas)On Apr 6, 2024, at 10:37 AM, ron minnich  wrote:openat gives you the effect of 'cd path; open file' without having to cd. I don't see a lot of benefit to it unless you're opening a lot of files at that path.

9fans
  / 9fans / see
discussions
  +
participants
  +
delivery options
Permalink

Re: [9fans] openat()

[Bakul Shah via 9fans]

To me this sounds very similar to open() given a path relative to your current 
working directory.

> On Apr 5, 2024, at 2:22 PM, ron minnich  wrote:
> 
> not so much what I want, I'm curious about ideas people have about 
> implementing it that I would not think of.
> 
> On Fri, Apr 5, 2024 at 1:38 PM Gorka Guardiola  > wrote:
>> Hmm sorry. Now I see what you want. Not to rewalk. You can use the chan of 
>> the dirfd and walk just the remainder cloning it and creating a new one. 
>> That way the openat provides the guarantees you want.
>> 
>> On Fri, Apr 5, 2024, 22:15 Gorka Guardiola > > wrote:
>>> I mean, if you want a new syscall jus copy or call the implementation of 
>>> these.
>>> 
>>> 
>>> On Fri, Apr 5, 2024, 22:12 Gorka Guardiola >> > wrote:
 ¿Isn't that fd2path, strcat and open?
 Or am I misunderstanding something?
 
 On Fri, Apr 5, 2024, 21:51 ron minnich >>> > wrote:
> One of the folks I worked with, when we pulled a big chunk of plan 9 into 
> akaros, commented that he had implemented openat on akaros. 
> 
> I don't want this to turn into a debate on the merits of openat; I am 
> more curious: if you went to implement openat on Plan 9, how would you go 
> about it? I have a few ideas but I'm more interested in your ideas.
> 
> Thanks
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0efc38028930341e0db8f794
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription