From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 22 May 2014 11:56:45 -0400 To: 9fans@9fans.net Message-ID: <1a387abb8b40a66c414b0110c8072f06@ladd.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] hgfs Topicbox-Message-UUID: edf3d3be-ead8-11e9-9d60-3106f5b1d025 thinking about the idea of a revision control file system brings me back = to some work i followed by brian stuart. his =CE=B8fs has a object store. = the object store allows arbitrary metadata and object size. the =E2=84=99 snapshot = device could be modified to take snapshots based on an arbitrary reference point, rath= er than "the last" snapshot. so in theory all the bits are there, they would jus= t 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 v= arious 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 implementa= tion of advanced techniques, self-contained, avoid configuration, use mechanism s= uch as namespaces instead. 2. run on as many systems as practical. do not break compatability with= out specific articulated reasons. 3. all changes are up for debate, but there is a clear path to decision = making. - erik