Re: [9fans] hgfs?

[Bakul Shah <bakul@bitblocks.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On Thu, 26 May 2011 20:16:11 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > > A project idea: murkyfs -- browse not just your own mercurial
> > > repo and also the one you cloned from! Extra points for
> > > mapping hg commands like push/pull/merge/diff in a useful way.
> > >
> > > Another idea is a better integration of acem + hg.  [One side
> > > effect using Eclipse is I have been thinking about how one
> > > might build a simple IDE around acme or something similar.]
> > >
> > >
> > http://ueber.net/code/r/hgfs
>
> 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".

May be the filesystem model is more like an electric motor
that powers all sorts of things given the right attachment!

> 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. But I am wondering just how far this model can be
pushed or extended seamlessly.

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"
- 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).

Now 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 .status  == hg status
- cat > .commit == hg commit
- cat .log == hg log
- echo -a > .revert == hg revert -a
- echo $url > .push == hg push $url
- echo $url > .pull == hg push -u $url

In fact the backend SCM doesn't have to be mercurial; it can
also git or even venti etc. Can we come up with a minimal set?

Do we gain anything by mapping $SCM commands to special files?
What about name clashes?