On Mon, 2005-03-28 at 20:09 -0600, John Arbash Meinel wrote: > Probably you don't want to use arch, because you really don't want to do > revision control. Unless you are trying to patch/merge the changes, you > should look into more of a backup system (like Amanda.)
No, I don't want backups...I really do want revision control. Here's the scenario: I've got software (http://onesis.org) that enables a single root filesystem to be used without any change on many functionally different machines (diskless clusters in my case). Consider the (very real) situation where there are many admins all making changes to this one root filesystem. I'm want documented changes, the ability to incorporate only particular changesets, and the ability to roll back to any previous revision. I want revision control. I've looked at several SCM systems (including Subversion and Bitkeeper), and I think Arch sounds very close to the solution I'm looking for. The problem is I need to retain permissions on all files, and be able to archive special files (mainly device files). > I think the problem is how do you do a diff of a FIFO with another FIFO? > Is it just presence/absence? > > You *really* don't want arch to consider /dev/hda as a file that it > would diff against some other /dev/hda. > Maybe for block items you would want to just record what their block > numbers. If you can come up with a reasonable definition, maybe it would > make sense. You're right. These kinds of files would need special handling, but it wouldn't be very difficult. The code snippet you referred to could be extended to handle 'special' files as well. I'm not familiar with all the internals of arch, but all of this is conceivable and should be fairly straight-forward since tar is the file-store. Tar is fully capable of storing device files and retaining permissions. The 'special' file diff for a FIFO would just check existence. A 'special' file diff on a char/block device would just look at the major/minor numbers of the device. Sockets would still be ignored. Changesets of 'special' files would simply invoke 'mkfifo' or 'mknod' as appropriate instead of 'patch' (or whatever). This is, of course, very UNIX-centric, but all the code could be #ifdef'd out for other platforms. > But really that would be easier to do by having a script that you run > which takes inventory of whatever you want, and then puts that into a > text file. Then you use arch to manage the text file. Certainly do-able, but not ideal. Like I said, I want to stuff an entire distribution into an archive. I don't just want to synchronize machines...rsync is suitable for that. I want to allow any remote machine (administrator) to 'check out' a fully configured OS image, make any changes to it (that could be committed back to a main archive), and then boot their cluster into that image (that part I've got covered). They could make changesets for their own particular needs and they could commit any fixes/updates back into the main archive. I've already got several 'repositories' of pre-configured OS images (RedHat, Fedora, Suse, Debian, Gentoo, etc.). However, anytime I copy an image to a remote machine, it is effectively gone. I never see any updates to it or any fixes to the configuration. I want to be able to roll those fixes back in to a main archive and share them with all the other machines that use that image. > Arch also doesn't maintain owner/group. Again because that doesn't make > sense in standard revctl. Because if you put your source somewhere, I > download it, it shouldn't have you as the owner, it should have me. > Otherwise I might not even be able to read it. Yes, but retaining permissions would be necessary in my case. Again, this is something that tar does well. A simple flag could tell the tar back-end to retain permissions on the archive. Of course only a privileged user (ie: root) could ever check out an archive, but that is fine. Revision control doesn't apply only to source code anymore. I've found several instances of people doing exactly what I'm looking for by hacking all kinds of scripts around a CVS repository. That sounds far to gruesome to me. I'd like a clean, fully revision-controlled, linux root filesystem. Conceptually, I think this doesn't sound too hard. Of course the devil is in the details. What do you think? -JE _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
