On Thu, 22 May 2014 07:36:54 +0200 lu...@proxima.alt.za wrote:
> > Though the idea of a scmfs (for checkins as well) and using
> > vac/venti as a backend is starting to appeal to me : )
>
> Let's open the discussion, Plan 9 has some baseline tools other OSes
> are still thinking about and will probably implement stupidly. Since
> RCS I've been thinking that there has to be a better way and CVS went
> a long way to satisfy my personal requirements. Now may well be the
> time to look at fresher options.
I am attaching an excerpt from an old email (May 26, 2011)
that I never sent. These ideas are not even half baked. But
may be they will trigger some creative thoughts.
On Thu, 26 May 2011 20:16:11 EDT erik quanstrom <quans...@quanstro.net> wrote:
>
> file servers are great, but hg concepts aren't really file-system oriented.
> it might be nice to be able to
> diff -c (default mybranch)^/sys/src/9/pc/mp.c
> but hg diff figures out all the alloying stuff, like the top-level of the
> repo anyway. also, ideas like push, pull, update, etc., don't map very well.
> so a hg file server seems to me a bit like, "have hammer, see nail".
I thik the filesystem model is more like an electric motor
that powers all sorts of things given the right attachments!
> if i'm missing why this is an interesting idea, i'd love to know what
> i don't see.
I partially agree with you; hence the suggestion about editor
integration.
It is just that I have wondering about just how far the FS
model can be pushed or extended seamlessly in various
directions.
In the context of SCMs, we can map a specific file version to
one specific path -- this is what hgfs above does. But what
about push/pull/commit etc.? One idea is to to map them to
operations on "magic" files.
For example,
- local file copies appear as normal files.
- cat .hg/status == hg status
- cat > .hg/commit == hg commit
- cat .hg/log == hg log
- echo -a > .hg/revert == hg revert -a
- echo $url > .hg/push == hg push $url
- echo $url > .hg/pull == hg push -u $url
- ls .hg/help
- cat .hg/help/push
In fact the backend SCM need not be mercurial; it can git,
venti etc. Can we come up with a minimal set of features?
Do we gain anything by mapping $SCM commands to special files?
The same question can be asked about many of existing plan9
filesystems. At least for me visualizing new uses is easier
when more things can be fitted in a simpler model.
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.
Example uses:
- A backup is nothing but a previous commit. A nightly
backup cron job to do "echo `{date} > .commit"
- an offsite backup is a `push'.
- Initial system install is like a clone.
- An OS upgrade is like a pull.
- 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.
- 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'.]
A better integration can inspire new uses:
- a timemachine like a gui can help quickly scroll through
changes in some file (or even a bird's eye view of changes
in all the files).
- combining versioning + auto push/pull with other filesystems
can open up new uses. You can keep your own daily archive of
http://nyt.com/ or see how a story develops by scrolling through
changes.
Just some things I was mulling about. As you can see there are
lots of open questions & half-baked ideas to sort through.
