Jani Averbach wrote:
> On 2004-06-21 20:58-0700, Steven Brown wrote:
>
>
>>The safest way is to just use the tried and true RCS approach. "ci
>>-l" the file initially, and "ci -l" every time you want to commit a
>>change. It'll drop the revision history file right next to the file
>>you're working on, which is perfect for things like /etc where each
>>file is usually a repository unit, and is highly visible to other
>>admins poking around /etc. It's probably the only use remaining for
>>RCS, but it fits the niche well.
>
>
> Well, I have now used SVN over one year to version my /etc and I have
> few comments to your statement:
>
> First of all, SVN really shines when you have to commit a logical
> change that spans over several config files. You know that you could
> always revert your system to the previous state with single command if
> something goes wrong. The second case when SVN marvels is when a
> package installs new config files: you just run 'svn st' and you will
> immediatelly see which files are new in /etc. Did I mention that with
> SVN you have automatically a backup of your /etc in another partition?
> Or how about sharing configuration between different machines?
>
> I am a co-admin of one system, and there we are using RCS based
> version system for /etc. And while RCS is better than nothing, it
> isn't even near where SVN is today.
>
> I don't understand how I could have administered my systems in the
> before-Subversion-age.
The problem is that Subversion can't understand (currently) the full
structure of /etc, like symlinks (I'm not sure how well it deals with
devices and sockets/pipes). Debian uses a lot of symlinks in there
(e.g., Apache 2). So to fully Subversionize the directory, a script to
capture and rebuild structure that couldn't be saved directly is needed,
which starts breaking down the glamour of version control. Since I
can't use it to fully version or backup the directory, I start comparing
it to other partial solutions, and in that space, I feel the traditional
admin 'RCS, backups, and changelogs' solution for is still the way to
go. Since the majority of program configurations are self-contained in
one file, there's very little lost feature-wise compared to a tool that
can handle multiple files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jun 22 07:08:10 2004