Intro to Distributed Version Control (Illustrated)

[…] Visual guide to distributed version control Filed under: code — Ralph Hockens @ 11:16 pm Intro to Distributed Version Control (Illustrated) […]

great read again!

Thanks Amit :slight_smile:

[…] O paper de Ian Clatworthy, desenvolvedor do Bazaar, sobre sistemas de controle de versão distribuídos procura demonstrar as vantagens de se adotar este modelo e dá sugestões sobre como escolher uma ferramenta, dentre as opções existentes. Há também, uma explicação sobre DVCS no site BetterExplained, versão ilustrada. […]

[…] Intro to Distributed Version Control (Illustrated) at […]

[…] In my quest to try and learn new things (more like trying to avoid being bored with stuff I’m doing) I decided to take a look at another version control system I had heard about called Git. According to it’s entry over at Wikipedia it is “…a distributed revision control / software configuration management project created by Linus Torvalds.” Yes, the same Linus Torvalds who created Linux. When I first heard about Git I thought to myself “why should I care that Subversion supposedly sucks and that distributed version control is awesome?”. So I decided to dig a little further. […]

[…] Intro to Distributed Version Control (Illustrated) […]

Пример ведения IT блога…

Я редко выделяю какой-то отдельный англоязычный блог, но вот этот, BetterExplained , заслуживает внимания…

[…] From Ian Clatworthy: Distributed Revision Control System Working in Subversion controlled environment, I had a headache in cleaning up the conflict when I need to merge branches and trunks changes together. This Distributed Revision Control System like Bazaar, seems will help me through the merging process. […]

[…] […]

[…] SP2 will initially be developed by me, though I expect to leave the role of lead developer after the core is done (though it will not have reached feature-parity with SimplePie 1). SP2 will be developed from a distributed version control system — most likely Mercurial, though git is also an option if people would prefer to use that. The current intention is that I will maintain the authoritative tree while all my minions do the coding for me. […]

[…] Intro to Distributed Version Control (Illustrated) […]

[…] This link has a more detailed explanation on how distributed source control works. […]

Hi Kalid. Thank you for this wonderful write-up. You recommended to start with Subversion, is that because it’s simpler? What do you think of tools like Trac? I just need a good tool for my website projects. Thank you again!

Hi Ildar, thanks for the comment. Yes, I’ve found regular VCS a good way to start. Subversion is pretty popular and works with many tools, like Trac. You can get subversion working first, then use Trac if you need project management. Personally I don’t use Trac for my projects.

Here’s an article on getting Subversion up and running with TortoiseSVN, a nice GUI client:

It’s nice to look at a directory and see what’s up to date and what isn’t.

Thanks, Kalid! TortoiseSVN looks very interesting, especially for people who don’t want to use the command line.

take a look at WANdisco ( which transforms SVN and CVS into true distributed VC systems and remove the disadvantages you mention here…

While the Linus talk on git at Google gives an overview of the motivation for git (basically, “it’s not CVS”), my followon Google Tech talk goes over the details of using git.

Hi Randal, thanks for the info!

[…] Are using subversion? you should take a look at Git. This weekend I switched my repository to use it, and I’m happy with it. The main difference is that it’s distributed rather then centralized, where each checkout is a it’s own branch with full revision history, which I definitely think “is the right thing to do.” The distributed model can easily simulate standard centralized model, while having flexibility of working in other ways. But theory aside, git is nice to work with, rather then tracking individual files it tracks the whole content, so it’s much less intrusive then subversion. While subversion puts innoying .svn folders in every folder of your project, git just has one .git folder in the project’s base folder. I really like that adding, renaming, deleting, and moving files around can be done without asking Git permission to do so :], with svn you have to tell in explicitly on the other hand…sure it’s not a big deal, but I like it that way. Here is a nice cheat sheet for Git. There is more to git of course, like space efficiency, speed, superior branching/merging, etc. etc., but the point is, you should check it out, it is a good tool. […]