On Fri, 27 May 2011 08:21:14 EDT erik quanstrom <quans...@quanstro.net> 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 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.
Yes.
> it
> sounds like you're proposing something completely different
> than hg, even if it's compatable on some level.
Perhaps a subset. I don't know.
> > - 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.
You can keep a `vendor' branch in sync with the base. local
changes in a separate `local' branch. Do a merge periodically.
> this is interesting, but what you're talking about sounds a
> lot more like user-controlled snapshotting than scm to me.
Use controlled snapshotting is basically what an scm does. In
addition you can revert changes, maintain alternative
branches, share your changes with others and so on.
> 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?
Yes, at any level. Wherever you might put .hg. But I haven't
worked out lots of things.
> 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 used to keep configurations under scm. Handy when
multiple machines have to be managed.
> in fact, i wonder how one would keep things sane.
> how would build some cannonical rules, like we have for
> the namespace (namespace(4))?
Don't know. Since you asked if this is an interesting idea I
wrote up what I was thinking about but that doesn't mean much
of it is worked out! This is research :-) Lots of half baked
ideas to sort through, lots of open questions. On prototyping
it may turn out none of it makes any sense.
> > - Conversely old commits can be spilled to a backup
> > media (current SCMs want the entire history online).
>
> backup media? what's that? ;-)
Or offsite.
A better integration can inspire new uses (at least for me
this is the case).
- 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.
- combining versioning + scripted push/pull can open up new
new uses. For instance, commit before refetching pages from
a website into webfs, and you can keep your own archive.
Your own wayback machine :-)
- since each changeset has a unique signature, you don't have
to fetch/keep an entire repo locally if you can fetch it
from another node (but you can). Instead you can share a
repo with other people and only keep your local changes.
- Given this, you can boot up a new machine, configure it
minimally, install this fs and start using the machine right
away as things will be fetched on demand. This is just
using existing mechanisms in an SCM in a new way (but
perhaps bending it in an extreme way).
