Andrew Lentvorski wrote: > Tracy R Reed wrote: >> Andrew Lentvorski wrote: >>> Gregory K. Ruiz-Ade wrote: >>>> On Aug 17, 2007, at 2:36 PM, Andrew Lentvorski wrote: >>>> >>>>> Mercurial is easy enough that for the first time since RCS, the >>>>> entire OS on my computer is now under source control. >> >> There is no reason why this would not work on Linux, is there? > > It should work fine on Linux, too. > >> What if you have code in your homedir checked out of hg and then you >> put your whole system under hg. Does hg drop a .hg dir or something >> like that in every dir on your whole system like I seem to recall that >> svn and cvs do? (or do they only do that in the top level dir under >> version control?) > > Only the top level directory gets a .hg file. > > To have recursive repositories (which I have, BTW), you add the lower > root directory to the .hgignore file of the parent. Mercurial commands > walk up the tree until they hit a .hg file and stop. > >> And aren't all of the constantly changing and transient files a real >> problem? > > Yes. However, you can add regex wildcards to your .hgignore file to > avoid pulling in things like your Firefox cache, etc. > > I don't quite have that down yet for my /home directory. I still > control too much (for example, my IMAP mail all gets committed in spite > of the fact that I have copies locally and on my server). However, I > don't tend to do an "hg commit" on my home directory more than about > once a week so I don't really mind. > > Development stays in /home/devel/<projectname> and each one of those is > their own repository. > >> And what if an upgrade changes, among other things, libc and you >> decide to revert it back? > > Isn't that just as much of problem if you upgrade forward? I see no > distinction. > >> Keeping a whole OS image under version control sounds >> like a neat idea. I'm just wondering how well it works in practice and >> how it interacts with the system package manager: Does it complement >> or work against it? > > Well, it's orthogonal. Obviously, if your system package manager is > *actually* doing its job, you probably don't need to put a VCS around > things. > > The problem I have is that I have yet to meet a package manager that > provides proper "revert" functions. Personally I think that wrapping a > package manager around a VCS or snapshot FS would probably be the next > logical step.
I was thinking the same thing. There is some common functionality that should be factorable, I suppose. It seems that VCS is a bigger concept than package manager, and it maybe could be extended to deal with dependencies and compatibilities, eh? How, I wonder? Maybe some kind of formalized representation of relationships, such that that metadata can be managed along with the usual files as data? I think I'm falling deeply into hand-waving territory, here. Discount freely. Hmmm, wasn't rpath's Conary described (maybe by LB?) as a step in this direction? > Upgrading then becomes a matter of installing a "changeset" from a > proper source. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
