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.
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 minni
On Thu, 22 May 2014 12:41:05 +0200 =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?=
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 t
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 wrote:
> Quoting Latchesar Ionkov :
>
> Who exactly do you think are the "we" that you are talking about?
>>
>>
>
> Al
On Thu, 22 May 2014 09:17:18 PDT ron minnich 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 overloa
c'mon. there's no point to namecalling.
- erik
Quoting Latchesar Ionkov :
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
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 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 wan
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 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 do
> 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
Quoting ron minnich :
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 tha
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
On Thu, May 22, 2014 at 6:17 PM, ron minnich 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
> 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 d
Quoting ron minnich :
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
has anyone looked at camlistore as a starting point? Written in Go,
which means it works on Plan 9.
ron
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 poin
On Thu, May 22, 2014 at 3:41 AM, Aram Hăvărneanu wrote:
> Skip Tavakkolian 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/h
Skip Tavakkolian 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? On
> It would be nice if you didn't hijack other people's threads.
Oh, dear, I apologise!
L.
On Thu, May 22, 2014 at 9:36 AM, wrote:
> ...
It would be nice if you didn't hijack other people's threads.
--
Aram Hăvărneanu
> 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 possi
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
...
%
Thanks, I love such toys :)
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 h
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 pla
> - 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
On Fri, 27 May 2011 08:21:14 EDT erik quanstrom 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 bu
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
overloo
> > 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, chang
On Thu, 26 May 2011 20:16:11 EDT erik quanstrom 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 integr
> > 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 b
On Thu, May 26, 2011 at 1:39 PM, Bakul Shah 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 mercuria
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 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 m
> 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
35 matches
Mail list logo
