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.
Upgrading then becomes a matter of installing a "changeset" from a
proper source.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list