[TAG] Version control for /etc

Kapil Hari Paranjape kapil at imsc.res.in
Fri Oct 26 09:47:45 MSD 2007


Dear Rick,

Thanks for these links:

On Thu, 25 Oct 2007, Rick Moen wrote:
>   https://wiki.ubuntu.com/VersionControlledEtc

> http://web.archive.org/web/20061206073756/http://blog.fxa.org/articles/category/scm

And thanks for clearing up any vestiges of doubt about choosing CVS.

> > Mercurial: One of the modern VC systems considered "notable" on
> > Rick Moen's knowledge base. One difficulty with "hg" is that it
> > insists on the "distributed" model. Putting the version control
> > history outside /etc (a la CVS) would require convoluted mounts.
> 
> You're actually mixing together a good thing and a bad one:  The
> distributed model is the good part, and nothing about it inherently 
> prevents what one wishes to achieve, here.  

I used "distributed model" rather loosely and you are right.

> Fantastic!  See, I didn't know that.  I've learned something useful
> today.  Thank you, Kapil.

Pleased to be of help.

I just noticed that there is mention of this approach on the ubuntu
wiki link that you sent me.

As I mentioned (and you are aware) there are some convoluted
mechanisms available to achieve almost this goal with the other SCMs.
For example,
	mount --bind /var/lib/repos/hg/etc.hg /etc/.hg
(for this the /etc/.hg directory has to exist which is a small bit of
cruft). After this Mercurial should work as expected.

A different approach would be to use /etc as a target rather than as
a working directory. The folks at infrastructures.org seem to believe
in this approach which uses a "Gold Server" as explained in
	http://www.infrastructures.org/bootstrap/gold.shtml

But basically, (as you suggest) keeping the working directory separate
from its VC history data --- but tied using a configuration file of
some kind would be the best. Even the cloning operation would be much
faster to set up and would have the (somewhat dubious) advantage of
working fast on file-systems which do not have hardlinks (FAT file systems!).

Regards,

Kapil.
--




More information about the TAG mailing list