Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

[Bakul Shah <bakul@bitblocks.com>]

On Thu, 22 May 2014 08:45:48 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> > Features such as atomic commits, changesets, branches, push,
> > pull, merge etc. can be useful in multiple contexts so it
> > would be nice if they can integrated smoothly in an FS.
> >
> > - Installing a package is like a pull (or if you built it
> >   locally, a commit)
> > - Uinstall is reverting the change.
> > - Each machine's config can be in its own branch.
>
> what is the advantage over seperate files?  imo, this complicates the issue.

I don't quite recall what I was thinking 3 years ago in a 30
minute window but I think the idea was that you have a set of
configuration files which all need to be consistent and
if you wanted to "roll back" changes, you'd have to undo
all those changes.

> > - You can use clone to create sandboxes.
> > - A commit makes your private temp view permanent and
> >   potentially visible to others.
> > - Conversely old commits can be spilled to a backup
> >   media (current SCMs want the entire history online).
> > - Without needing a permanent connection you can `pull' data.
> >   [never have to do `9fs sources; ls /n/sources/contrib'.]
>
> this is a nice list, but i think a key point is not being teased out.
> the dump file systems are linear.  there is a full order of system
> archives.  in hg, there is a full order of the tip, but not so of
> branches in general.  in git, multiple orders (not sure if they're
> full or not) can be imposed on a set of hashes.

So if we do SCM right, backups are just a subset, right?!  No,
don't believe that.  No time to explore this right now but I
think dumps are at a different (lower) level from SCM data.

> another key point is that all distributed scms that i've used clone
> entire systems.  but what would be more interesting is to clone, say,
> /sys/src or some proto-based subset of the system, while using the
> main file system for everything else.  imagine you want to work on
> the kernel, and imagine that you keep console log files.  clearly
> you want to see both the new log entries, and the modified kernel.

Actually with something like venti as the store, `clone' is
trivial! Just find the hash for a particular changeset you want
to clone and you can build the rest on demand. `rebase' or
`pull' will be more painful.

> i would be concerned that this really challenges the plan 9 model
> of namespaces.  one would have to figure out how to keep oneself
> out of namespace hell if one were to build this into a file system and
> use it heavily.

Your concern is a bit premature.  We are just handwaving right
now!  I am interested in finding out just how far we can push
the plan9 model -- and if the current model doesn't naturally
fall out of any extended model, we'd know.