[9fans] hgfs

[Skip Tavakkolian]

i'm playing with hgfs. here are some first observations/thoughts.

for a given repository foo, if the repository mounted on /n/hg, had a
hierarchy like:

 /n/hg
  /ctl
  /versions
  /foo

it would feel more natural if i could do:

% cat /n/hg/versions  # list versions
...
% echo version rev1  /n/hg/ctl # pull + update -r rev1, etc.
% ls /n/hg/foo
 # list of rev1 files
% echo version rev2  /n/hg/ctl
% ls /n/hg/foo
... # list of rev2 files, etc
% ed /n/hg/foo/main.c 'EOF'
$a
// a useless comment
.
w
q
EOF
% cat 'EOF' /n/hg/ctl
tag rev1beta1  # tag this version
note added a silly comment to main.c and tagged this version as beta1 #
commit string?
push  # push the changes upstream, etc.
EOF

etc.

it would be nice to map as many hg/git operations to file operations as
possible. for the rest providing special files (ctl, versions, etc) and
directives don't seem out of place.

Re: [9fans] hgfs

[lucio]

 it would be nice to map as many hg/git operations to file operations as
 possible. for the rest providing special files (ctl, versions, etc) and
 directives don't seem out of place.

I've been thinking about combining synthetic file servers with shell
functionality, where Plan 9's rc (but possibly other shells, if
necessary) are initialised with a suite of commands, some of which,
like functions, will come from the namespace, while others will be
provided by a bind over /bin from the appropriate, fabricated
namespace.

I guess, in a way, this an extension of the concept used in busybox.

The idea then would be to start up a shell environment (not unlike
ape/psh) and navigate within it with conventional commands being
mapped to the appropriate procedures automatically.

I know this is a bit obscure, but I think a few examples attached to
something like hgfs (which I have steered clear of because of my
aversion to having Python in Plan 9 - I plead guilty to bigotism)
would explain things somewhat.

The nearest I've come to implementing some of these ideas, is an rc
startup script I wrote to access the OpenLDAP client commands.  I use
it infrequently, but it does save me a lot of bother when I do.

The script, attached, is in turn invoked in a smaller, private script
(I call it $home/bin/rc/Ldap):

#!/bin/rc
window rc -m rcldap

L += 1
# rcmain for LDAP shell instance
if(~ $#home 0) home=/
if(~ $#ifs 0) ifs=' 
'
prompt=('ldap% ' '  ')
echo -n LDAP /dev/label
if(~ $rcname ?.out) prompt=('broken! ' '')
if(flag p) path=/bin
if not{
finit
if(~ $#path 0) path=(. /bin)
}
test -d /n/ldap -a -d /n/ldap/bin || {
ramfs -m /n/ldap
mkdir /n/ldap/bin /n/ldap/tmp
for (x in add search delete modify modrdn compare passwd whoami) {
touch /n/ldap/bin/$x
test -e /$objtype/bin/pub/ldap^$x  bind 
/$objtype/bin/pub/ldap^$x /n/ldap/bin/$x
}
bind /$objtype/bin/pub/ldapmodify /n/ldap/bin/add
bind -b /n/ldap/bin /bin
}
test -f $home/lib/ldaprc  . $home/lib/ldaprc
fn ep {
echo -n $1^' = ' | tr a-z A-Z
test -e '#e/'^$1  cat '#e/'^$1
echo ''
}
fn e {
ep admin
ep attrib
ep base
ep binddn
ep filter
ep host
ep opts
ep scope
}
fn s {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#binddn 0)  arg=($arg -D^$binddn)
if(! ~ $#base 0)arg=($arg -b^$base)
if(! ~ $#scope 0)   arg=($arg -s^$scope)
if(! ~ $#opts 0)arg=($arg $opts)
if(! ~ $#filter 0)  arg=($arg $filter)
if(! ~ $#attrib 0)  arg=($arg $attrib)
if(flag x) echo search $arg $*
search $arg $*
}
fn a {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#admin 0)   arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(flag x)  echo add -a $arg
add -a $arg
}
fn m {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#admin 0)   arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(flag x) echo modify $arg
modify $arg
}
fn d {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#admin 0)   arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(flag x) echo delete $arg $*
delete $arg $*
}
fn p {
if(~ $#* 0){
filter='(objectclass=person)'}
if not {
filter='((objectclass=person)(cn='^$*^'))'}
if(~ $#attrib 1){
filter='('^$filter^'('^$attrib(1)^'=*))'
}
s
}
fn enhance {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(~ $#admin 0){
if(! ~ $#binddn 0)  arg=($arg -D^$binddn)
}
if not arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(! ~ $#* 0){
dn=$1; shift
}
if(! ~ $#* 0){
attrib=$1; shift
}
if(flag x)echo modify $arg
if(! ~ $#dn 0){
if(flag x){
echo dn: $dn
echo changetype: modify
echo add: $attrib
echo $attrib: $*
echo
}
{
echo dn: $dn
echo changetype: modify
echo add: $attrib
echo $attrib: $*
echo
} | modify $arg
}
if not modify $arg
}
if(! ~ $#cflag 0){
if(flag l  /bin/test -r $home/lib/profile) . $home/lib/profile
status=''
eval $cflag
}
if not if(flag i){
if(flag l  /bin/test -r $home/lib/profile) . $home/lib/profile
status=''

Re: [9fans] hgfs

[Aram Hăvărneanu]

On Thu, May 22, 2014 at 9:36 AM,  lu...@proxima.alt.za wrote:
 ...

It would be nice if you didn't hijack other people's threads.

-- 
Aram Hăvărneanu

Re: [9fans] hgfs

[lucio]

 It would be nice if you didn't hijack other people's threads.

Oh, dear, I apologise!

L.

Re: [9fans] hgfs

[Aram Hăvărneanu]

Skip Tavakkolian skip.tavakkol...@gmail.com wrote:
 % cat /n/hg/versions  # list versions
 ...
 % echo version rev1  /n/hg/ctl # pull + update -r rev1, etc.
 % ls /n/hg/foo
  # list of rev1 files
 % echo version rev2  /n/hg/ctl
 % ls /n/hg/foo
 ... # list of rev2 files, etc

What would be the point of this? Once you have a version (revision)
you can just bind the subtree where you want it. I don't see the
point in having this special switching code inside hgfs. Plan 9
provides the necessary functionality.

 % ed /n/hg/foo/main.c 'EOF'
 $a
 // a useless comment
 .
 w
 q
 EOF
 % cat 'EOF' /n/hg/ctl
 tag rev1beta1  # tag this version
 note added a silly comment to main.c and tagged this version
 as beta1 # commit string?

Somebody would have to write the code, right now hgfs is read-only.
I don't know how hard it would be. Are you offering?

-- 
Aram Hăvărneanu

Re: [9fans] hgfs

[Skip Tavakkolian]

On Thu, May 22, 2014 at 3:41 AM, Aram Hăvărneanu ara...@mgk.ro wrote:

 Skip Tavakkolian skip.tavakkol...@gmail.com wrote:
  % cat /n/hg/versions  # list versions
  ...
  % echo version rev1  /n/hg/ctl # pull + update -r rev1, etc.
  % ls /n/hg/foo
   # list of rev1 files
  % echo version rev2  /n/hg/ctl
  % ls /n/hg/foo
  ... # list of rev2 files, etc

 What would be the point of this? Once you have a version (revision)
 you can just bind the subtree where you want it. I don't see the
 point in having this special switching code inside hgfs. Plan 9
 provides the necessary functionality.


true, but now you'd have to have another layer of scripts, etc. why not
just make it look the way it should?



  % ed /n/hg/foo/main.c 'EOF'
  $a
  // a useless comment
  .
  w
  q
  EOF
  % cat 'EOF' /n/hg/ctl
  tag rev1beta1  # tag this version
  note added a silly comment to main.c and tagged this version
  as beta1 # commit string?

 Somebody would have to write the code, right now hgfs is read-only.
 I don't know how hard it would be. Are you offering?


i've been thinking about this (as obviously others have been too -- see
Bakul's post on another thread), but since i don't have enough rope at the
moment to fathom the depths of hg and git, i'm offering it for comment or
dare :)

-Skip

--
 Aram Hăvărneanu

Re: [9fans] hgfs

[erik quanstrom]

thinking about the idea of a revision control file system brings me back to
some work i followed by brian stuart.  his θfs has a object store.  the object
store allows arbitrary metadata and object size.  the ℙ snapshot device could
be modified to take snapshots based on an arbitrary reference point, rather than
the last snapshot.  so in theory all the bits are there, they would just need 
to
be put together in a different way.  fun little thing to think about.

in any event, back to the subject at hand.  this in-depth discussion of various
revision control systems seems to assume that revision control is the key issue.

i have seen plan 9-derived projects fail using codereview and google code
because there wasn't a shared goal.  so i would identify it as the key
issue  the goal is strategy, revision control is tactics.

instead of a goal or vision, perhaps values are more down to earth.
for example, a common value for kernel folks is never break user land.

let me propose this draft.
1.  keep with the original value system of plan 9: e.g. simple implementation of
advanced techniques, self-contained, avoid configuration, use mechanism such
as namespaces instead.

2.  run on as many systems as practical.  do not break compatability without
specific articulated reasons.

3.  all changes are up for debate, but there is a clear path to decision making.

- erik

Re: [9fans] hgfs

[ron minnich]

has anyone looked at camlistore as a starting point? Written in Go,
which means it works on Plan 9.

ron

Re: [9fans] hgfs

[Kurt H Maier]

Quoting ron minnich rminn...@gmail.com:


has anyone looked at camlistore as a starting point? Written in Go,
which means it works on Plan 9.


That means it works on *one architecture* of Plan 9.

khm

Re: [9fans] hgfs

[lucio]

 in any event, back to the subject at hand.  this in-depth discussion of 
 various
 revision control systems seems to assume that revision control is the key 
 issue.

Much as I agree with you that clear objectives are essential to any
type of success (a tautology if ever there was one - what do you
measure success against, if the objectives aren't clear?), it was the
code review bit that I perceived as an obstacle.

But you're right, and your objectives make a fine starting point.
They ought to attract discussion, though, as they seem to me a little
too specialised (?).  I want a little time to ponder over them,
anyway, as it takes me a while to grasp all the ramifications.

L.

Re: [9fans] hgfs

[Aram Hăvărneanu]

On Thu, May 22, 2014 at 6:17 PM, ron minnich rminn...@gmail.com wrote:
 has anyone looked at camlistore as a starting point? Written in Go,
 which means it works on Plan 9.

No, it doesn't. I uses FUSE for God's sake. Camlistore is also 65kLOC

-- 
Aram Hăvărneanu

Re: [9fans] hgfs

[ron minnich]

I'm beginning to remember why I redirected this list to /dev/null. I
think I'm going to resume.

Enjoy your ever-shrinking place in the world, folks; it's clear that
you enjoy it. It's also clear that nobody else cares any more.

ron

Re: [9fans] hgfs

[Kurt H Maier]

Quoting ron minnich rminn...@gmail.com:


I'm beginning to remember why I redirected this list to /dev/null. I
think I'm going to resume.


thanks for letting us know


Enjoy your ever-shrinking place in the world, folks; it's clear that
you enjoy it. It's also clear that nobody else cares any more.


I'm sorry that popularity is so important to you.  I look forward
to any future technical contributions you may make regarding plan
9 or software that runs on plan 9.


khm

Re: [9fans] hgfs

[Aram Hăvărneanu]

 I'm beginning to remember why I redirected this list to /dev/null. I
 think I'm going to resume.

Good riddance, we don't want your insults here. We don't want your
nsec, and we don't want your GPL.

 Enjoy your ever-shrinking place in the world, folks; it's clear that
 you enjoy it. It's also clear that nobody else cares any more.

Hey, we're not coming to your Googleplex to insult you, but you come
here to insult us. We don't serve koolaid here, so go back and drink
your koolaid at Google.

Thank you for choosing 9fans OSX/Linux. Have a nice day.

-- 
Aram Hăvărneanu

Re: [9fans] hgfs

[Latchesar Ionkov]

Who exactly do you think are the we that you are talking about?

Lucho


On Thu, May 22, 2014 at 12:51 PM, Aram Hăvărneanu ara...@mgk.ro wrote:

  I'm beginning to remember why I redirected this list to /dev/null. I
  think I'm going to resume.

 Good riddance, we don't want your insults here. We don't want your
 nsec, and we don't want your GPL.

  Enjoy your ever-shrinking place in the world, folks; it's clear that
  you enjoy it. It's also clear that nobody else cares any more.

 Hey, we're not coming to your Googleplex to insult you, but you come
 here to insult us. We don't serve koolaid here, so go back and drink
 your koolaid at Google.

 Thank you for choosing 9fans OSX/Linux. Have a nice day.

 --
 Aram Hăvărneanu

Re: [9fans] hgfs

[Skip Tavakkolian]

you're entitled to your opinion, but please don't speak for everyone.


On Thu, May 22, 2014 at 11:51 AM, Aram Hăvărneanu ara...@mgk.ro wrote:

  I'm beginning to remember why I redirected this list to /dev/null. I
  think I'm going to resume.

 Good riddance, we don't want your insults here. We don't want your
 nsec, and we don't want your GPL.

  Enjoy your ever-shrinking place in the world, folks; it's clear that
  you enjoy it. It's also clear that nobody else cares any more.

 Hey, we're not coming to your Googleplex to insult you, but you come
 here to insult us. We don't serve koolaid here, so go back and drink
 your koolaid at Google.

 Thank you for choosing 9fans OSX/Linux. Have a nice day.

 --
 Aram Hăvărneanu

Re: [9fans] hgfs

[Kurt H Maier]

Quoting Latchesar Ionkov lu...@ionkov.net:


Who exactly do you think are the we that you are talking about?




All the unpopular, irrelevant people who regularly force poor Ron
to loudly, manually pipe this list into /dev/null instead of just
unsubscribing.

khm

Re: [9fans] hgfs

[erik quanstrom]

c'mon.  there's no point to namecalling.

- erik

Re: [9fans] hgfs

[Bakul Shah]

On Thu, 22 May 2014 09:17:18 PDT ron minnich rminn...@gmail.com wrote:
 has anyone looked at camlistore as a starting point? Written in Go,
 which means it works on Plan 9.

I will take a look at it but Ron, if you are still on this
channel, may be you can describe how it will help here?
[And, please don't overload /dev/null. Just use a 'killfile']

Re: [9fans] hgfs

[Latchesar Ionkov]

So that means you and Aram. It is interesting that unpopular and irrelevant
very often comes in combination with loud.

Lucho


On Thu, May 22, 2014 at 1:13 PM, Kurt H Maier k...@sciops.net wrote:

 Quoting Latchesar Ionkov lu...@ionkov.net:

  Who exactly do you think are the we that you are talking about?



 All the unpopular, irrelevant people who regularly force poor Ron
 to loudly, manually pipe this list into /dev/null instead of just
 unsubscribing.

 khm

Re: [9fans] hgfs

[Bakul Shah]

On Thu, 22 May 2014 12:41:05 +0200 =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= 
ara...@mgk.ro wrote:
 
 What would be the point of this? Once you have a version (revision)
 you can just bind the subtree where you want it. I don't see the
 point in having this special switching code inside hgfs. Plan 9
 provides the necessary functionality.

I agree on this specific point.

If I am working on branch A and I want to switch to B, git
forces me to commit or stash my changes. So even after
gadzillion lines of code it still doesn't do the right thing.
A tool should not force singlethreading on me.  And hg is no
better in this regard.  This limitation need not exist on
plan9.

Re: [9fans] hgfs

[Skip Tavakkolian]

camilstore's storage idea is interesting, but i admit i've only played with
it and briefly. i think you're referring to the fact it keeps all versions
that are put into it and the fact that anything stored can have any
metadata (json) associated with it.


On Thu, May 22, 2014 at 9:17 AM, ron minnich rminn...@gmail.com wrote:

 has anyone looked at camlistore as a starting point? Written in Go,
 which means it works on Plan 9.

 ron

Re: [9fans] hgfs

[hiro]

To get ahead in the game of bullying always single one person out,
don't try to even do two at the same time or they might team up.

 It is interesting that unpopular and irrelevant
 very often comes in combination with loud.

No.

Re: [9fans] hgfs

[hiro]

Thanks, I love such toys :)

[9fans] hgfs

[cinap_lenrek]

wrote a hgfs for plan9 that gives you read only access to all revisions
in a mercurial repository.

it provides a directory per revision. the revision directory can use
decimal revision number:

123/

or
f32acf03d/

this is a first step towards native tools for plan9 to work with
mercurial.

in plan9front, we forced ourselfs to use the python hg implementation
--
cinap

[9fans] hgfs

[cinap_lenrek]

forgot the mention some bits:

hgfs gives you one directory per revision. a revision dir
looks like this:

cpu% cd /n/hg/99
cpu% ls -l
d-r-xr-xr-x M 37623 stanley.lieber hgfs   0 Apr 17 22:19 changes
d-r-xr-xr-x M 37623 stanley.lieber hgfs   0 Apr 17 22:19 files
--r--r--r-- M 37623 stanley.lieber hgfs 157 Apr 17 22:19 log
--r--r--r-- M 37623 stanley.lieber hgfs  16 Apr 17 22:19 rev1
--r--r--r-- M 37623 stanley.lieber hgfs   0 Apr 17 22:19 rev2
--r--r--r-- M 37623 stanley.lieber hgfs  25 Apr 17 22:19 who
--r--r--r-- M 37623 stanley.lieber hgfs  56 Apr 17 22:19 why

files/ contains the whole snapshot.
changes/ is like files, but contains only the files that where
changed in that revision.

log is the raw mercurial changelog entry.

rev1 and rev2 contain the directory names of the parent revisions.

the who file contains the commiter and why the commit message.

i'm thinking about providing some history(1) like rc scripts that
help with some daily tasks.

any suggestions and ideas are welcome.

source:
/n/sources/contrib/cinap_lenrek/hgfs.tgz
http://9hal.ath.cx/usr/cinap_lenrek/hgfs.tgz

--
cinap

Re: [9fans] hgfs?

[Bakul Shah]

On Thu, 26 May 2011 20:16:11 EDT erik quanstrom quans...@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?

Re: [9fans] hgfs?

[erik quanstrom]

  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.

the problem here is that no scm that i know of has storage
capabilities.  you'd still need a file system underneath.  it
sounds like you're proposing something completely different
than hg, even if it's compatable on some level.

 - An OS upgrade is like a pull.

is like, but they're different.  you can't take every file from
the base.  one of the problems with replica is that it's hard
to work out the local differences.  hg doesn't make this any
easier.

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

this is interesting, but what you're talking about sounds a
lot more like user-controlled snapshotting than scm to me.

do you propose being able to do this at any level in the fs
heirarchy, or just at the root?  if not just at the root, how
is a namespace constructed?

i'm not sure why one would want each machine's config in
its own branch.  remerging default could be a real administrative
pain.  in fact, i wonder how one would keep things sane.
how would build some cannonical rules, like we have for
the namespace (namespace(4))?

 - Conversely old commits can be spilled to a backup
   media (current SCMs want the entire history online).

backup media?  what's that?  ;-)

i'd be against any scheme that moves data from its original
location.  the worm property is just great.  i've reconstructed
full worms from partial worms a few times.  russ posted an
interesting story about recovering a venti this way. 

- erik

http://www.quanstro.net/magic/man2html/4/namespace

Re: [9fans] hgfs?

[Lucio De Re]

On Fri, May 27, 2011 at 08:21:14AM -0400, erik quanstrom wrote:
 
 do you propose being able to do this at any level in the fs
 heirarchy, or just at the root?  if not just at the root, how
 is a namespace constructed?
 
I'm going to throw a small pebble into this pond, in case it goes
overlooked: proto.  I'm not sure how helpful it might be, but it pops
up in my head whenever I think about revision control for a native Plan
9 platform.

++L

Re: [9fans] hgfs?

[Bakul Shah]

On Fri, 27 May 2011 08:21:14 EDT erik quanstrom quans...@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.
 
  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.
 
 the problem here is that no scm that i know of has storage
 capabilities.  you'd still need a file system underneath.

Yes.

 it
 sounds like you're proposing something completely different
 than hg, even if it's compatable on some level.

Perhaps a subset. I don't know.

  - An OS upgrade is like a pull.
 
 is like, but they're different.  you can't take every file from
 the base.  one of the problems with replica is that it's hard
 to work out the local differences.  hg doesn't make this any
 easier.

You can keep a `vendor' branch in sync with the base.  local
changes in a separate `local' branch. Do a merge periodically.

 this is interesting, but what you're talking about sounds a
 lot more like user-controlled snapshotting than scm to me.

Use controlled snapshotting is basically what an scm does.  In
addition you can revert changes, maintain alternative
branches, share your changes with others and so on.

 do you propose being able to do this at any level in the fs
 heirarchy, or just at the root?  if not just at the root, how
 is a namespace constructed?

Yes, at any level. Wherever you might put .hg.  But I haven't
worked out lots of things.

 i'm not sure why one would want each machine's config in
 its own branch.  remerging default could be a real administrative
 pain.

In fact I used to keep configurations under scm.  Handy when
multiple machines have to be managed.

 in fact, i wonder how one would keep things sane.
 how would build some cannonical rules, like we have for
 the namespace (namespace(4))?

Don't know.  Since you asked if this is an interesting idea I
wrote up what I was thinking about but that doesn't mean much
of it is worked out!  This is research :-) Lots of half baked
ideas to sort through, lots of open questions.  On prototyping
it may turn out none of it makes any sense.

  - Conversely old commits can be spilled to a backup
media (current SCMs want the entire history online).
 
 backup media?  what's that?  ;-)

Or offsite.

A better integration can inspire new uses (at least for me
this is the case).
- a timemachine like program to animate changes in a file (or
  even a bird's eye view of changes in an entire repo). Scroll
  backward/forward in time.
- combining versioning + scripted push/pull can open up new
  new uses. For instance, commit before refetching pages from
  a website into webfs, and you can keep your own archive.
  Your own wayback machine :-)
- since each changeset has a unique signature, you don't have
  to fetch/keep an entire repo locally if you can fetch it
  from another node (but you can).  Instead you can share a
  repo with other people and only keep your local changes.
- Given this, you can boot up a new machine, configure it
  minimally, install this fs and start using the machine right
  away as things will be fetched on demand.  This is just
  using existing mechanisms in an SCM in a new way (but
  perhaps bending it in an extreme way).

Re: [9fans] hgfs?

[erik quanstrom]

 - a timemachine like program to animate changes in a file (or
   even a bird's eye view of changes in an entire repo). Scroll
   backward/forward in time.

history(1).

- erik

[9fans] hgfs?

[Bakul Shah]

 Typically the way to do this is to create your own public fork, and
 then send a pull request to the maintainer of whoever you forked from
 since hg has the distributed model.

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.]

Re: [9fans] hgfs?

[simon softnet]

do you even realize that plan 9 / unix is supposed to be an IDE?

On Thu, May 26, 2011 at 6:39 PM, Bakul Shah ba...@bitblocks.com wrote:

  Typically the way to do this is to create your own public fork, and
  then send a pull request to the maintainer of whoever you forked from
  since hg has the distributed model.

 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.]

Re: [9fans] hgfs?

[Iruatã Souza]

On Thu, May 26, 2011 at 1:39 PM, Bakul Shah ba...@bitblocks.com wrote:
 Typically the way to do this is to create your own public fork, and
 then send a pull request to the maintainer of whoever you forked from
 since hg has the distributed model.

 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

Re: [9fans] hgfs?

[erik quanstrom]

  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.

if i'm missing why this is an interesting idea, i'd love to know what
i don't see.

- erik