Why would I not want a central repository in versioning? SVN vs. Git question

Question

Duplicates:

• http://stackoverflow.com/questions/740053/why-should-i-use-git-instead-of-svn
• http://stackoverflow.com/questions/161541/svn-vs-git
• http://stackoverflow.com/questions/871/why-is-git-better-than-subversion

I'm sure I've asked it wrong but I read that Git doesn't use a central repository like SVN does. One, I don't understand how you can have a decentralized version control system. I'm sure it works because so many use it but I don't understand the concept.

How can you have something everyone uses but not a centralized repository to hold the source code?

I suppose this is more of a git vs. svn also, Which do you use? I read that git is better but not as integrated in most IDE tools as SVN.

I'm still learning.

Thank you.

Answer 1

With distributed version-control-systems every working copy is a own repository (and a own branch). At any time you can synchronize changes to other repositories. Projects that use such version-control often have one or some repositories, that are the 'main' branches. But everyone can maintain an alternative repository.

Answer 2

You can still have a centralized repository. The difference is that you have a fully functioning repository server on your local machine which allows you to work completely disconnected, while still having the ability to track changes and check in. In order to share with other people their needs to be a central repository somewhere that changes can be merged to. However it's not required.

Answer 3

Having a decentralized repository means that you can commit to different places.

For example, you develop for an application on a Git repository. So what you do is essentially clone it locally. That way you can commit changes locally, so you don't need constant access to the main repo, and you can push your changes out when they're completed locally.

For larger projects with lots of users this is a great feature.

With SVN, you have a single main server repository. If you want to have incremental commits and only commit them to the main development, you create a branch and work off of that. However, you still need connectivity to the remote repository to commit changes.

So Git essentially lets you have your own local branch, without needed connectivity to the main repository server.

If you don't need this type of distribution, the extra management overhead of making sure everyone's local repository is sync'ed correctly can become a hassle.

Answer 4

I use Bazaar, so this might be a slightly different answer than a Git user would give, but:

Just because the VCS is decentralized does not prevent you from having a single, authoritative branch. All branches are equal, but you would still maintain an "official trunk" to tag releases on. For example, although their are thousands of branches of the Linux code, Linus's branch is what gets released as the "official" version.

Advantages to the decentralized model are that you're not dependent on the continued operation/cooperation of the central server and maintainer. If the main server goes down, you still have a complete version of the code to work on. If the maintainer refuses to accept your patches, there will be no (technological) impediment to simply maintaining your own branch.

Answer 5

You very often have a central repository of the "blessed" state of your code with Git. It's just that you can set up many more repository / contributor layouts than with SVN.

For instance, under the "main" repository, you can have the repositories for specific modules that are completely independent. So developers on a module can share changes between them as they work, and they only push out changes to the central one when they're done with a dev cycle.

To put it in simpler terms: everything SVN can do, Git can, and then some. (Give or take some details: Git doesn't have svn:externals or file locking for instance.)

I use IntelliJ IDEA, and its Git support is first-class. Also, Git already comes with fairly powerful interactive tools built in, both graphical and command-line. I find I use my IDE less.

Answer 6

I see two major benefits to Git over SVN:

1. No single point of failure. GitHub went down today and many people complained, but they could keep working with their teams because each checked out copy is a full repository that can be diff'd, merged, etc.

2. Eliminates political problems. As organizations grow, the number of internal projects increases, and thus the number of dependencies. Git makes it easy for each organizational unit to "own" copies of each project, which can make reduce headaches when creating new versions. It also means that a team can start up their own branch, make improvements, and then offer the branch back to the primary owners version of the project -- all without going through the headaches of getting permission on a different group's systems.

Answer 7

The point of a DVCS is not "avoiding a central repository." Most DVCS-based projects I see have some notion of a common HEAD--people push patches to that HEAD, and that's where releases come from.

Instead, the primary advantage of a DVCS is that every working copy allows revision control. This has three primary advantages.

1. Convenience. If I add a new feature, I can commit it--and have a nice record of a working version of the code--without either having a network handy, or having to shove my possibly-broken code into other peoples' hands.
2. Control over parallel development. Totally independently, I can work on one feature set, and use revision control in all the ways that we know it makes development better, while someone else can commit patches to the same code (so they can take advantage of revision control) without interfering with my developme
3. Branching, merging, and the like. DVCSes tend to have much better support--since it's an inherent idea in a distributed system--for branching. If I don't like what the head of a project does, it's trivial for me to branch the project. I pull HEAD, start committing to that repo, and can send that repo to anyone who wants my branch. Similarly, in the context of #2, it's far easier to deal with multiple patch sets from different people.

Answer 8

Honestly, I prefer git over svn mostly because it's ridiculously fast and because it gives you way more (dangerous) power on how to deal with commits, and has pretty decent merging.

It being distributed is only cool inasmuch I can have my own commits in my forks of open source projects.

And github is awesome. Really. Awesome.

So, the immediate advantage of git's model of distributed repository is that you get to keep the entire repository locally, and that makes things awesomely fast. And you don't have to worry about your half-way commits screwing it up for everyone. (alternatively, you don't have to go through the pain of branching in svn)

Answer 9

That always confused me too before I started using Git. People like to overemphasise how different it is.

The truth is that you can, and most likely will, set up your Git system to have a single "master" repostiory. What's different with Git is that every "working directory" also gets its own client repository. A large amount of Git's design is for merging code back and forth between client repositories and a parent.

If you want to go with a single master repository sitting on a server somewhere, and all users being direct clients of that repository, you can easily do that. What makes Git really different is that you don't have to do that. You could instead have a big tree of repositories from worker, to subgroup, to test group, to master if you want. You could instead set up a chain from worker to development master (updated frequently by developers) to remote customer site (updated rarely by the customer when they want a fix, and can get the private network up between them in Ethiopia and you in Toledo). The topology and workflow is up to you, not the tool.

My suggestion would be to try out Git yourself for a small (or pretend) project. Once you see how it works, you'll begin to see the possibilities.