9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] hgfs
Date: Thu, 22 May 2014 11:56:45 -0400	[thread overview]
Message-ID: <1a387abb8b40a66c414b0110c8072f06@ladd.quanstro.net> (raw)
In-Reply-To: <CAJSxfmK-Eopfn3+eHhrcHsSDJ7g-YCMFu8RZqStd0FPCh9r2Uw@mail.gmail.com>

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



  reply	other threads:[~2014-05-22 15:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22  6:52 Skip Tavakkolian
2014-05-22  7:36 ` lucio
2014-05-22  9:54   ` Aram Hăvărneanu
2014-05-22 10:30     ` lucio
2014-05-22 10:41 ` Aram Hăvărneanu
2014-05-22 15:35   ` Skip Tavakkolian
2014-05-22 15:56     ` erik quanstrom [this message]
2014-05-22 16:17       ` ron minnich
2014-05-22 16:21         ` Kurt H Maier
2014-05-22 16:31         ` Aram Hăvărneanu
2014-05-22 18:37           ` ron minnich
2014-05-22 18:45             ` Kurt H Maier
2014-05-22 18:51             ` Aram Hăvărneanu
2014-05-22 19:02               ` Latchesar Ionkov
2014-05-22 19:13                 ` Kurt H Maier
2014-05-22 19:16                   ` erik quanstrom
2014-05-22 19:23                   ` Latchesar Ionkov
2014-05-23  3:45                     ` hiro
2014-05-22 19:11               ` Skip Tavakkolian
2014-05-22 19:23         ` Bakul Shah
2014-05-22 19:47         ` Skip Tavakkolian
2014-05-22 16:20       ` lucio
2014-05-22 19:46   ` Bakul Shah
  -- strict thread matches above, loose matches on Subject: below --
2011-06-27  5:43 cinap_lenrek
2011-06-27 13:15 ` hiro
2011-06-27  5:09 cinap_lenrek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a387abb8b40a66c414b0110c8072f06@ladd.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).