Live data from Hacker News

Subversion in 2010 and Beyond

subversion.wandisco.com

31–32 of 32 posts

Re: Subversion in 2010 and Beyond

#31
post #8

Earlier quoted context omitted.

To the best of my knowledge, git is for smaller teams that need more of an ability to be dynamic (maybe web apps dev) whereas subversion is for larger teams that need centralization (network/server; maybe large systems - however Torvalds would disagree here since git was initially for kernel dev).

Having Git be a distributed VCS doesn't mean it can't have a centralized server though. If you want you can use Git as something very similar to Subversion--you just lose out on a lot of the nicest parts of Git. I think the biggest challenge with using Git in a large organization is training a large number of people to use it. You can do a fair amount of development on a Subversion project knowing just how to update…

> I think the biggest challenge with using Git in a large organization is training a large number of people to use it. You can do a fair amount of development on a Subversion project knowing just how to update and commit. The same does not hold true of Git.

Is that because you also have to know how to push?

You can push git down to the LCD and have the same dumb VCS workflows. I think some people get hung up on thinking that new features being available must mean that you need to incorporate those new features into your workflows.

Re: Subversion in 2010 and Beyond

#32
post #29
post #11

Earlier quoted context omitted.

We've had this debate before, but something along the lines of: * No GUI for Git on Windows * Everything knows how to work with Subversion already (tools, testing, continuous integration, idiots) * Companies like centrally controlled and backed up solutions * Why change when what you have works for you

> Companies like centrally controlled and backed up solutions git wins fast over svn for backups. git backups are redundant, always up-to-date, easily verifiable, and easy to turn into proper master repositories. The more people you have working on a project, the harder it gets for anything to get lost.

To be fair to the subversion guys, its pretty darn easy to setup real-time backups. Use svnsync and hook it up in some post-commit hook.

Having said that, to have git completely backed up, it's not as simple as a clone. You will need to mirror another repository so that you can get all of the branches, tags, etc. Additionally you will need some sort of post-receive hook so that your mirror is kept up-to-date.

Now, my conclusion with backups for svn and git - both need some intervention. Its not as simple as "press this button and it just works".

Post reply on HN