Do we need a DVCS for a school project?

Question

We are about to start a simple webservice project with some JSP/servlet code as part of a course. We are a team of 4 and 3 of us have not used Version Control Software, ever. I plan to host the project on google code so that we can work on our time and still have access to code, version control etc. I need to choose between SVN and Mecurial/GIT. Given that the code it fairly small, is there any specific advantage of choosing DVCS instead of SVN? I feel learning SVN is easier compared to Git/Mercurial.

PS: GUI clients will make life easier. Are there any good ones for Git?

PPS: I am leaning slightly towards DVCS because I want to learn it and hey! school years are the best time to learn!

Answer 1

The two biggest choices are between git and Subversion. Git is a distributed version control system while Subversion is centralized. As I tell many people, they're different, not one is better and one is worse. Each has their own advantages depending upon the circumstances.

Subversion is much, much easier to use and has much better documentation. Git complexity comes from it being a distributed system, so you have the local repository and the remote repository which means there are now two repositories you're sending updates to. This can become quite confusing for many people -- especially people new to version control systems.

I suggest you download Subversion, and read the Subversion on line manual and play around with it. This is not to say to use Subversion. It's just to get you to understand how to use a version control system.

Now, to satisfy the Git fans out there: Git has one big advantage over Subversion: It's distributed. In Subversion you must have a centralized repository. That means setting up an Apache server, or at least running the svnserve Subversion server process on some machine that's accessible to everyone. You have one of those lying around? Most small teams don't.

Where Git shines in situations like yours is that you don't need a centralized server running Git. Everyone has a copy of the entire repository, and you can pass around the updates directly between the members of your team without checking your changes into a centralized server. You can send Git patches to each other via email. Or, you can even use a centralized Git repository in Dropbox and push and pull local copies from there. (Don't ever use that repository directly!). The main problem is making sure everyone on your team is getting the same updates as everyone else. This is where Git can breakdown if you're not careful.

Now, if you do happen to have a centralized server, and rather use Subversion, it's pretty simple setting up a Subversion repository server. Subversion comes with svnserve which is a very lightweight server and it can be setup as a Windows service. If you prefer Apache httpd as a server, you can get freely available Subversion server packages from many different sources. Here are a few:

• VisualSVN: Windows only. Free unless you want to do something fancy like use LDAP, Active Directory, or SSL.¹
• UberSVN: Works on Windows, Mac, or Linux. Same limitations as VisualSVN.¹
• CollabNet Subversion Edge: Completely open source solution. Not as easy to setup as the other two, but it's not all that difficult. This comes ready to use LDAP/Active Directory for user accounts, and it's pretty simple to setup SSL certificates.

---

¹ These packages are the complete Apache httpd and Subversion package all combined into a single easy install. If you forgo the GUI front end, you can setup LDAP/Active Directory or SSL yourself. You can't use the front end to do this without paying for the pro version. However, I'm not sure exactly what their license agreement says about that.

Answer 2

Contrary to previous answer, I strongly recommend don't use Git, at least now. I'm too lazy to repeat my points and start flamewar with Git-fanatics again. But - choosing Git as first SCM (and DVCS) for the most part of team is worst choice.

I feel learning SVN is easier compared to Git/Mercurial

Learning curves for SVN and Hg may be considered almost equal (some different headaches are on both sides)

Given that the code it fairly small, is there any specific advantage of choosing DVCS instead of SVN?

Without repeating discussed a lot of times points (thanks to @AD7six for links) - yes, there are... some...

1. With Subversion, you (team) must to have and maintain at least one central server and access to it. With Mercurial's hg serve everybody have p2p communication on demand
2. Novice can step on the SVN-rake (noted a lot "Merge Hell", f.e.) rather easy: it depends from codebase-size only partially, it's mostly workflow, style-dependent: long-time branches without in-process syncing, tree-conflict on heavy refactoring of code (usual case on early stages), ignoring branching and huge unmanageable commits ("trunk must always work" mantra)

---

From another POV:

1. CVCS (as class and SVN as "Best in Class") will live and be used in corporates a lot of years (IMNSHO) - and have ability to use Subversion in good way will be always plus

2. Subversion automagically teaches discipline and accuracy in the design and planning, while in DVCS it's only agreements, not requirements (to some degree, sure)

TBC

Answer 3

If most of you haven't used any Version Control Software before, I would suggest you start with Mercurial. Git is Mercurial's bigger brother, and can be a bit intimidating.

There are two major rules for using version control:

1. Check in early, check in often.
2. Don't commit broken code.

Without Distributed Version control these rules would conflict with each other strongly.

You'd need a very mature and disciplined team to make this work with Subversion.

With Mercurial or Git, developers commit to their private clones many times per hour. Once they are satisfied and their code is stable, they pull in the latest changes from the central repository. If that merge is successful, your version becomes the new 'trunk', 'master', or 'default', while keeping the history of both streams.

Check out Joel Spolsky's HgInit for the full story. Also check out Bitbucket; they offer free Git or Mercurial hosting for teams of up to five people. And of course, there's github.