Re: [9fans] Man pages for add-ons

[erik quanstrom <quanstro@quanstro.net>]

> I see this as a little more complicated for two reasons.  1) administrating
> distributed systems with group supplied applications that are widely used but
> not part of the OS,

one of the key bits of plan 9 is that the fileserver has always been a
network fileserver.  at coraid we have ~35 plan 9 machines in athens
(including testing, &c) and one fileserver.

> and 2) maintenance and development cycles.  How do you
> propose managing the source/executables for ver 1.* (stable) 2.* (stable), 2.*
> (experimental), and maybe even 1.* (backport)?

we don't do that.  you're supposing more testing cycles than there are
development cycles for plan 9.

> Even for my personal stuff I
> have had lack of versioning bite me -- I was working on a spatially-explicit
> modeling project, and had made some updates.  One of the ecologists came in
> and asked me for some data which was not generated in the original modeling
> runs, so I added it... only to find that the new version of could not read the
> old input...  Took days to reconstruct everything.

another key tenent of the plan 9 world is the dump filesystem.
i run ken's fileservers so i speak to that.  each day, a "dump" of
the filesystem is taken.  that dump is a read-only archive.  modern
lingo for such a beast might be a "persistent snapshot".  these are
never erased.  see bind(1) and history(1) for interesting applications.
using fossil+venti is the same except you can also have ephemerial
snapshots and the dump schedule is more flexible.

while this is not version control, it works so well that almost nobody
bothers with actual version control.  i feel really vulnerable on
linux without the dump.

> To make matters worse,
> this was in response to a review in a good journal, so time was of the
> essence.  So, in this case I had maybe 20 users at 6 universities in 3
> countries running at least two incompatible versions.  When I talk to these
> people I needed to know which they were using, and fix any bugs for the
> appropriate version.  I cannot expect them to stop what they are doing and
> simply upgrade at my whim.  I should also note that it often takes 1.5 to 5
> years from the start of an ecological field project to when it is published.
> So, users might be using a given version of software for years before they
> complete their projects.

the plan 9 model is different.  it's the one true version model.
great care is taken in development to avoid creating regressions.
so the extra work of maintaing many versions is avoided.  it may
not work for you, but give it a try before you say it doesn't work.

- erik