Versioning /etc with subversion is safe?

[Azangod]

Hi there,
the scenario is a production server where there is no tollerance for errors, where every etc-update session is pure fear.

Merging config files sometimes becomes tricky with the endless question "keep the old version ? better grab the new version and apply the personalizations or keep the old in the risk of a new-born option default value would do something nasty?"

My answer is: why not to use a cvs?
I know subversion wich works flawlessy for my work but I'm no guru and I'm wondering if there may be relevant security issues in this approach. well... first of all I don't know how to save permissions and ownerships of files stored.

So, before trying, I'm wondering (and asking) if there are serious drawbacks into doing this.

[OneOfOne]

I personally use git, i have this git alias

[Azangod]

Thanks, I've heard of many admins using git, but nothing about subversion.
I'm wondering why.
It's because GIT is old & well know or there are some other issues about subversion. Or simply subversion does'nt fit for this particular task?

[depontius]

I believe subversion is older than GIT. I've been considering moving /etc into subversion, but the details of the process and job, along with my lacking understanding of subversion have held me back. At home I have 2 servers and 3 clients. I think I'd like a tree structure using branches, with one root, split into servers and clients, the each of those split into per-system. But I've never really worked like that with subversion - at work I use tags to mark release points, and those tags don't seem to "inherit" changes from the trunk. My impression is that branches are like tags, with the similar inheritance issue, and at that point it alls seems to start looking like enough extra work with enough pitfalls that I never get around to it.

I've learned enough about subversion to make it do what I need to do at work. I could probably stand to learn quite a bit more.
_________________
.sigs waste space and bandwidth

[Azangod]

I did'nt know that subversion is older than git. I've always believed that git was a milestone, the vcs choice of kenerl developers from the stone era.

Maybe i did'nt understood your use of subversion but seems to me that there is something odd.

[depontius]

[Azangod]

Nice story founded on wiki... another piece of code "once granted for free" that after some time becomes commercial-only.
At least I could say I've learned something new today.

It seems I've to take a good look at GIT for my admin issues.. one time or another... if I'm can find the time

About subversion I suggest this guide: http://svnbook.red-bean.com/
The merge process is quite simple when you have understood the logic that lies beneath. I've tryed svn two years ago and since then I've never thought of moving nor trying something else: it simply has everithing needed. At least for what I need it for.
Mybe one of the colest features is its capability of managing folders that permits to have many project as needed in a single repository! No need to manage a repos-per-project.

[depontius]

I use the redbook regularly - for what I need to do at work. Home admin is on a time-available basis, and I just don't have that much to spare.
_________________
.sigs waste space and bandwidth

[Azangod]

I know! Days of 48 hours wont help much in the long run... but sometimes I really would like to have more time

[V-Li]

A distributed VCS like Bazaar, Git, Mercurial or Darcs should be the better choice as you can transfer the whole history easily by just copying the directory.

[Azangod]

[V-Li]

Inside of /etc you have a .git or .bzr or .whatever directory which contains the whole (!) repository. So copying the /etc directory over to another machine preserves all the history without creating a Subversion repository there, importing and so on.

[Azangod]

[depontius]

[Azangod]

[V-Li]

Git packs quite well, although binary files press a big problem here, but that is usually not the target for such a version control system.

[Massimo B.]

Just to point out my idea using mercurial for /etc: Planning Mercurial for /etc ...
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770

[cwr]

I'd be inclined to use Mercurial, (or even Bazaar, which I haven't tried) rather than Subversion.
You're dealing with text files, which a DVCS is at home with, and they all handle merges better
than Subversion. Check the docs on http://mercurial.selenic.com before making a decision;
they give a good overview of VCS and DVCS advantages and disadvantages.

On the whole, avoid Git - it's a good idea for the kernel, but it has a major learning curve.
It took me five minutes to learn enough to start using Mercurial, with I suppose half a
dozen essential commands, and it really is a very powerful and convenient piece of
software.

Will

[Ant P.]

I've found git repositories with a working directory checkout to be smaller than the corresponding SVN checkout alone, even with huge (1.5GB) directory trees of binaries and 5 years of history. Also it doesn't pollute the entire FS tree with hidden files like SVN does.

[rh1]

[Massimo B.]

Continuing the discussion about mercurial here...
I had long time discussions with mercurial people at #mercurial channel. Summarily what they said is, Mercurial is not SVN and Mercurial is not the right tool.
This is mainly because of the requirements and methods I tried to explain:

I have different Linux machines each having more or less different configuration. Mainly I need to track /etc, but because sometimes I also add usr/share/kde/....kdmrc or even var/lib/portage/world I made / being a mercurial repo (beware of Bug 284673!). Each machine gets its own feature branch. I never merge feature branches. I think about having a seperate feature branch being a template branch with default configurations.
Now what is not the way of thinking in mercurial is what I often need: I would need to branch files directly. Say I have adapted etc/conf.d/local.start on hostA and next time on hostB I would need to merge parts of that file.
Mercurial people say, a revision is for the complete set of files. You can merge branches and revisions of branches, but never single files. Ok there are a lot of Mercurial Extensions, some of them could do the job:

• Convert extension and using a filemap
  
• Transplant extension

The Mercurial way of merging actually is: Go back to the revision the bug appears, fix it (making a unnamed or even named branch), comit and merge. For our case that would mean: If there is a version of a file that might be distributed among other branches this must be a pre-branch revision and you can branch from that. This model absolutely breaks with what I planned.
Does anybody has any suggestion about that?

Anyway, I'm already using Mercurial on this purpose for a while now. I need to merge a file? No problem, I do

[Massimo B.]

[wcg]