From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 27 May 2011 08:21:14 -0400 To: 9fans@9fans.net Message-ID: <6e074b83a55da47bb35cafb80845edc2@ladd.quanstro.net> In-Reply-To: <20110527081252.CA6F2B827@mail.bitblocks.com> References: <35f361459403c30512191d203286cd76@swcp.com> <20110526163958.02922B827@mail.bitblocks.com> <20110527081252.CA6F2B827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] hgfs? Topicbox-Message-UUID: e973a474-ead6-11e9-9d60-3106f5b1d025 > > 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