2

I have seen many quotes on the subject of "Git vs SVN", the usually anwser is

  1. you can commit anywhere
  2. save space
  3. branch fast

...

But here I want to have discussion on whether is good for Continuous Delivery? It seems to me that Git encourage us to branch often, but that work against the notion of Continuous Delivery who advocates merge to mainline often, branch when release not on feature.

So, I am a little puzzled when I want to choose a version control system for our Continous Delivery, Git or SVN?

What's your opinion?

Ozair Kafray
  • 13,351
  • 8
  • 59
  • 84
welkinwalker
  • 2,062
  • 3
  • 18
  • 21
  • It does not seem that this question is a good fit for SO. You can find dozens (if not hundreds) discussions on the topic just by Googling. According to the [FAQ](http://stackoverflow.com/faq#dontask): *You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page*. – malenkiy_scot Jun 20 '12 at 10:39
  • There seems no good discussion on the question, all the debates is svn VS git, but when it comes to CI and CD, not appropriate answer. You can google for "git svn continous integration delivery", the top post is this one. – welkinwalker Jun 21 '12 at 02:36
  • I guess, git provides per se more opportunities. Theoretically. Practically, you need to agree on a process and setup an integrated chain of tools for your workflow. The latter is bothering me now, everything so complicated to setup unless you're not on github. – Olha Puzhay Nov 22 '12 at 16:24

3 Answers3

0

First of all, I would never choose svn. There might be some cases, but in general git is much more flexible.

That said, let's look into Continous Delivery (CD). From my point of view, this means to deploy often. It also means you need some kind of Continous Integration (CI) where you run your tests and decide if the version gets shipped or not. It also means you need some kind of workflow on how to determine which version gets tested and shipped.

Back in the svn days, we didn't have any branches because it was to troubling. Everyone would commit into the repository and then someone responsible for shipping would see if everything is ok and use his version of the repository to ship.

This is cleary not going to work with CD because you wantat least one stable branch. This branch should only be populated with stable releases of the software which then gets into production. You also want a testing branch where features get merged that are ready to be tested and then deployed. And you want any number of development branches, where not-ready-yet features are located.

Make no mistake: You can do CD with svn. It's just that git was designed to work well with many branches and remote repositories on different servers while svn was designed to work as a single repository where everybody can commit to.

You also might get a problem with user management. I don't know about svn, but I think you can not have different rights for different branches. This means that everyone with write access to the repo can break your application and have this stuff deployed. On the other hand it's easy to set up a repository where only a senior developer have write access and which gets deployed. All other developers work on another remote repository. The person in charge then pulls all the stuff and pushes them to the other server so they get deployed.

This all comes from the fact that git was designed to have many repositories which get merged together, branched, forked and patched on a regular basis (open source projects). On the other hand, svn is more of a company software where you need to version your files and maybe have a branch or two for different versions of your software, but not much more.

Last thing: I would choose git over svn every single day.

Sgoettschkes
  • 13,141
  • 5
  • 60
  • 78
0

Regardless of Subversion or Git if the workflow is correct you should be fine. Each version control system supports branches and some folks think the grass in greener on one side or the other but the fact is version control is a commodity.

For infrastructure around a version control system, typically referred to as application lifecycle management (like continuous integration) a more important goal is the maturity of tools used to integrate the version control system with other pieces of the puzzle. Tight IDE integration is nice as well to make the developer's time as productive as possible.

You'll find a lot of Git zealots active on forums but there's a reason Subversion has (and is today) the most popular version control system. I try to be agnostic but to counter some of the "svn sucks" rhetoric you might want to read this: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

vinnyjames
  • 2,040
  • 18
  • 26
  • Yes, I agree that continous delivery is more of a disipline than a tool selection. SVN is mature, Git is on the road to mature – welkinwalker Jun 21 '12 at 03:02
  • I know a lot of companies prefer a central server for continuous integration because with a DVCS it's up to the developer if they commit their work to a local repo, their co-workers repo or the 'main' repository. With the central server you're guaranteed that all commits will happen where the continuous integration tools can pick them up and with DVCS you have to rely on individual contributors following the process. – vinnyjames Jun 21 '12 at 13:11
0

Your concern is valid. From http://martinfowler.com/bliki/FeatureBranch.html

Although many people associate DVCSs with feature branching, they can be used with CI. All you need to do is mark one branch on one repository as the mainline. If everyone pulls and pushes to that every day, then you have a CI mainline. Indeed with a disciplined team, I would usually prefer to use a DVCS on a CI project than a centralized one. With a less disciplined team I would worry that a DVCS would nudge people towards long lived branches, while a centralized VCS and a reluctance to branch nudges them towards frequent mainline commits.

ottodidakt
  • 3,631
  • 4
  • 28
  • 34