I was reading up on distributed version control and while I think it offers a fresh new look on version control compared to something like Subversion, I am having trouble understanding the key concept of distributed version control. From what I have read, the biggest advantages of distributed version control is that is handles changes and merging a lot easier than server/client version control but I just don't see how it does. Lets say you are building a game engine with subversion. You breakup the sections of the engine so lets say we have a branch for the rendering, sound, input, scripting, and terrain. You have 5 separate teams would on each of these sections. When each team is done a ready to push their changes to the mainline of development, they will have to merge their branch with the mainline. With distributed version control, the only difference I see is that instead of have different branches for each team, each team now has a different repository and when they are down, all those repositories will need to be merged into the main repository. What am I missing that makes distributed version control handle merging so much easier?

The tools are better, I gather. I've never used distributed VCS enough to have to merge (I found it too cumbersome relative to SVN for small, one-man projects and have no need or ability to try it for something larger, yet).

I would comment that I think your workflow of having a different branch for "rendering, sound, input" et cetera is extremely cumbersome, even in a traditional SCM paradigm.

The point of distributed version control is that every user pulls his own copy of the repository instead of checking out a mere working copy.
that way, everyone can use the full advantages of version control without the need to commit their work into the central repository constantly or create a new branch.
the first is problematic because often complex changes take a long time and break the code for everybody in the meantime. the second is problematic, because it would just clutter the repository if everyone in a large project would create new branches all the time.
so everyone works with his own copy of the repository and only pushes the changes back to the central repository when he really is done.

I switched from SVN to Git about 4 months ago. It's really much nicer.

One big thing is that I find myself doing 'microcommits' in a way, rather than waiting for a full feature-set to be finished. Since commits are only local on my machine they don't bother other people using the central repository.

Also, branching is much more useful since it doesn't clutter up a central repository. Say, you are working on a new feature. You make a branch for the feature and begin work. Someone contacts you and needs a bug fix. You just switch back to the original branch and fix the bug... push... switch back to the branch you were working on the new feature with. No need to checkout the repository into another directory or revert or anything. It's pretty handy. If the bug you fixed is important to your new feature you can easily merge it with your feature branch, or wait until you are done, etc.

I wished I would already use git, as right now (after an act of relocation) I still have to wait another week for my internet-wireup, and hence can't commit changes from home to the vcs (svn). I could checkout my svn repository at work, and merge my hobby-work in, but then that is undefined behaviour w.r.t. my working contract and a bit clumsy.

Afaik, you can use git with a SVN repository. Git pulls from SVN, you can use it locally and git pushes back to SVN.

Quote: Original post by maximAL
Afaik, you can use git with a SVN repository. Git pulls from SVN, you can use it locally and git pushes back to SVN.

I did not know it can push back to SVN, thanks for the hint. Now I only hope that my latest Debian CD-ROMS have compatible packages :)

edit: Otoh, I think I have git already installed to pull from some other repositories :)