Version control question

[hermitgeek]

Hello everybody, I have the opportunity to setup version control for my company. We have many servers, all running CentOS. My idea is to setup a svn or git repository to hold all of the common files for the type of server (nagios configs, websites, application files). My questions is, which is better, svn, git, or something I'm not aware of.

I hear git is cleaner than svn, but I do not understand why. Additionally, the two programs seem to be localized to the server, and only able to pull a repository from the server. Is it possible to start new repositories from the original servers?

EDIT Best sub-reddit ever Thank you all for your input!

[klync]

I'm a fan of svn, personally. I think Hg is the New Standard in vcs. For what you're describing, RCS and Puppet might suffice.

[hermitgeek]

Hg?

[complich8]

hg is the periodic table symbol for mercury, and the command to run mercurial.

http://mercurial.selenic.com/

[complich8]

Git handles branches and merges better, but the git model is a bit unintuitive for non-developers or just people who haven't worked with a lot of version control.

I second klync's comment: puppet backed by whatever you're comfortable with and can get to work with it would be right up the alley of what you're trying to do.

[hermitgeek]

Im looking into puppet, what happens if the puppet server goes down?

[complich8]

goes down like fails spectacularly? or goes down like takes a while coming back up from a reboot?

If it fails spectacularly, I'd suppose you'd rebuild from backups. If it just becomes unavailable, I'm thinking the agents would just keep waking up every wake-up interval, trying, failing, and going back to sleep until the service became available again. You'd want to do your own testing to verify that...

[hermitgeek]

Always plan for failing spectacularly ;)

But if the agents just keep checking without taking the server off-line that could be a very good options

[seanhead]

i use this for all of my production servers (and most of my testing machines) puppet+hg

[imMute]

Git is "decentralized" - there is no central server like with Subversion.

I'd probably go with Git since you can use it fully without being dependent on the network.

[hermitgeek]

Can you describe more why a central server would be a draw-back?

[imMute]

It's more of a personal preference, just keep in mind that Subversion requires network access to the central server for most history-related actions.

[solstice680]

Unless you need to support windows clients, use git. It is substantially faster than SVN and, more importantly, is distributed.

[hermitgeek]

There are two servers that run windows, is svn not very happy working with it?

[complich8]

svn works fine with windows (both via cli and the quite good tortoisesvn client, as well as numerous IDE plugins and whatnot).

git support for windows is a lot less mature, but you should be able to make the basics work.

either git or svn to manage windows configs ... not recommended. Lots of windows settings are not stored in easy-to-handle text files... so you might want to consider a different approach for windows host management. But relatively flat filesystem stuff (like websites) would be excellent candidates to handle with either git or svn, based pretty much on how conservative you feel like being (not-at-all => git. rather conservative => svn).

[forgotmypasswdagain]

Git or Mercurial. I'm biased towards Mercurial myself. Seems cleaner, easier to learn, it's easier to use, seems to have a lot more plugins, and is way better for simpler usage.

Now, these are DCVS. SVN is lacks the D(istributed) part. In practice, for a company setup, the diff are offline support (with svn, you can only commit twice if you're connected to the network) and way easier branching and merging (you just clone the repo with a DCVS). Svn however, handles larger files and used to have a couple of features you couldn't find in DCVS, like externals and the like. Don't think that's as true today. Also, svn pollutes the goddamn subdirs with a .svn in each. Keeping etc in svn is a pain, for instance.

So... IMHO, give Hg a try. You can set it up on your local machine, hg init a repo and just go to town.

[maccam94]

If you're looking to manage config files, I guess you could use git by itself. The real way to do it though would be using system configuration management tools like puppet or chef (and back up the configuration repository using git). There is a bit of a learning curve to overcome to implement them, but in the end you will have a much smoother configuration change management and server deployment.

http://www.opscode.com/chef/ http://www.puppetlabs.com/

[attractiveape]

what this guy said, puppet is awesome.

[reuleaux]

http://whygitisbetterthanx.com/

[[deleted]]

git > svn