[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn import of working directory

From: Brian Mathis <bmathis_at_directedge.com>
Date: 2004-03-23 05:29:19 CET

Derek Scherger wrote:

> So what will you do when you want to check out your /etc config to a
> second machine? I'm currently struggling to set up svn with common and
> unique configurations from a small (i.e. home) network and it isn't so
> clean.
> There's a bunch of places in the code that have problems if the target
> directory or file already exist. I'm looking into the idea of checking
> out only the admin (i.e. .svn) directories over top of an existing
> "working copy" that just isn't associated with any particular repository.
> I have had some negative reactions to this idea a long time ago when
> cvs was the topic, but I really can't see any significant problems
> myself. There won't be any "damage" to the existing tree if no
> directories or files are touched (i.e. create only .svn directories
> where their parent directory already exists). If a directory is "in
> the way" that's perfect, just go into it and keep going. If a file is
> in the way, just leave it alone and create the associated admin info.
> If a directory is missing, do not create it but do create the
> associated admin info. Once this is all done, an svn diff should show
> the state of the current "working copy" verses the HEAD and anything
> that was different should show up as changed.
> This isn't a problem that's particularly unique to svn though, I can't
> seem to find any vc system that does what I want, which makes me
> wonder if what I want is crazy...
> There is a hint that handling the "sysadmin/many machines" case that
> I'm talking about might be sensible on the arch wiki at
> http://wiki.gnuarch.org/moin.cgi/Versioning_20strategies but the page
> has yet to be created which is unfortunate.
> The basic problem is that machines will share some common config
> (internal machines mta config in /etc/postfix) and also have some
> unique config (/etc/fstab). At the moment I have an svn repository
> with /config/common, /config/foo and /config/bar where foo and bar are
> the machine specific things. With this I can switch parts of the
> working copy trees to their machine specific repository locations and
> it works ok. The problem comes in when I decide that some new config
> files should be in svn, I can add them on one machine just fine, but
> there are other machines that also already have these
> files/directories and an update is blocked because they already exist.
> Any thoughts, solutions, ideas?

Once again I will propose that a VC type system is not the correct type
of system for storing system configuration files, specfically because of
what you just mentioned.

Anyone doing this should really take a look at cfengine, which is
designed for this sort of thing:
and a nice intro here:

You can always keep the cfengine files in svn. Otherwise, you wind up
making more problems than the solution you are trying to solve -
creating more and more non-standard scripts to keep your system in
place, forcing svn to grab things from here and there when it really
shouldn't be.

I love svn and I'm also a sysadmin of 10 years - svn just isn't the
right tool here.

Brian Mathis
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 05:29:55 2004

This is an archived mail posted to the Subversion Users mailing list.