[9fans] hgfs

[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

[hiro]

Thanks, I love such toys :)

[9fans] hgfs

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1456 bytes --]

Re: [9fans] hgfs

[lucio]

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

> 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

[-- Attachment #2: rcldap --]
[-- Type: text/plain, Size: 2844 bytes --]

# 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=''
	if(! ~ $#* 0) . $*
	. -i '#d/0'
}
if not if(~ $#* 0) . '#d/0'
if not{
	status=''
	. $*
}
exit $status

Re: [9fans] hgfs

[Aram Hăvărneanu]

On Thu, May 22, 2014 at 9:36 AM,  <lucio@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.tavakkolian@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]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

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

> Skip Tavakkolian <skip.tavakkolian@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
>
>

[-- Attachment #2: Type: text/html, Size: 2482 bytes --]

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 <rminnich@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

[Aram Hăvărneanu]

On Thu, May 22, 2014 at 6:17 PM, ron minnich <rminnich@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 <rminnich@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]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

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 <aram.h@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
>
>

[-- Attachment #2: Type: text/html, Size: 1304 bytes --]

Re: [9fans] hgfs

[Kurt H Maier]

Quoting Latchesar Ionkov <lucho@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

[Latchesar Ionkov]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

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 <khm@sciops.net> wrote:

> Quoting Latchesar Ionkov <lucho@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
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1137 bytes --]

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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

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 <aram.h@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
>
>

[-- Attachment #2: Type: text/html, Size: 1267 bytes --]

Re: [9fans] hgfs

[Bakul Shah]

On Thu, 22 May 2014 09:17:18 PDT ron minnich <rminnich@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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

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 <rminnich@gmail.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 831 bytes --]

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

[Bakul Shah]

On Thu, 22 May 2014 12:41:05 +0200 =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= <aram.h@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.

[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