From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 22 May 2014 08:45:48 EDT." <9fcb286589cf3ef81a8855fad9ebc547@mikro.quanstro.net> References: <20140522060008.6058CB827@mail.bitblocks.com> <9fcb286589cf3ef81a8855fad9ebc547@mikro.quanstro.net> Date: Thu, 22 May 2014 13:05:11 -0700 From: Bakul Shah Message-Id: <20140522200511.41E8FB82A@mail.bitblocks.com> Subject: Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53] Topicbox-Message-UUID: eefec278-ead8-11e9-9d60-3106f5b1d025 On Thu, 22 May 2014 08:45:48 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. > > > > - 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. > > what is the advantage over seperate files? imo, this complicates the issue. I don't quite recall what I was thinking 3 years ago in a 30 minute window but I think the idea was that you have a set of configuration files which all need to be consistent and if you wanted to "roll back" changes, you'd have to undo all those changes. > > - You can use clone to create sandboxes. > > - A commit makes your private temp view permanent and > > potentially visible to others. > > - Conversely old commits can be spilled to a backup > > media (current SCMs want the entire history online). > > - Without needing a permanent connection you can `pull' data. > > [never have to do `9fs sources; ls /n/sources/contrib'.] > > this is a nice list, but i think a key point is not being teased out. > the dump file systems are linear. there is a full order of system > archives. in hg, there is a full order of the tip, but not so of > branches in general. in git, multiple orders (not sure if they're > full or not) can be imposed on a set of hashes. So if we do SCM right, backups are just a subset, right?! No, don't believe that. No time to explore this right now but I think dumps are at a different (lower) level from SCM data. > another key point is that all distributed scms that i've used clone > entire systems. but what would be more interesting is to clone, say, > /sys/src or some proto-based subset of the system, while using the > main file system for everything else. imagine you want to work on > the kernel, and imagine that you keep console log files. clearly > you want to see both the new log entries, and the modified kernel. Actually with something like venti as the store, `clone' is trivial! Just find the hash for a particular changeset you want to clone and you can build the rest on demand. `rebase' or `pull' will be more painful. > i would be concerned that this really challenges the plan 9 model > of namespaces. one would have to figure out how to keep oneself > out of namespace hell if one were to build this into a file system and > use it heavily. Your concern is a bit premature. We are just handwaving right now! I am interested in finding out just how far we can push the plan9 model -- and if the current model doesn't naturally fall out of any extended model, we'd know.