[…] Intro to Distributed Version Control (Illustrated) | BetterExplained DVCS illustrated. (tags: mercurial subversion) […]
Hi Kalid,
Very well written article. Cleared out the pros and cons about DVCS for me!
Maybe you can help me on this one. Im currently looking for a version control tool for our devision. We support Oracle software, mostly custom code.
Sometimes code needs to be changed in case to fix errors or for further development. Therefore it needs version control. We are used to work with no more than one person on the same object on the same time because merging afterwards is very complex.
So we developed a tool where we can claim objects. Once an object is claimed, an other person isnt allowed to develop that specific object.
Now we need a more sophisticated tool, like subversion or mercurial. But, what would be your advise? In a centralized system we are still able to claim a source(by locking) but a distributed cant do that, can they.
My question is, wich one should I pick? I really like DVCS(particularly HG with Tortoise) but sources cant be claimed. I ask myself, how bad is that actually?
Hope you can give some advice on this. I dont expect a plug and play answer offcourse!
Hi Johan, glad you enjoyed the article! Great question – it’s hard to say, but if just starting out I’d begin with Subversion.
Centralized systems are easier to understand and get going with, and the locking feature is pretty nice.
I believe there are ways to export Subversion to a distributed system later if you find you need to do that (article here: http://ww2.samhart.com/node/49).
Hope this helps!
easy to read and easy to be read
haha…great article to teach many ppl out there
>.^
Thanks, glad you enjoyed it.
Nice visual representation and I learned a lot. But I’m still not seeing how merges are easier than Subversion. Can you compare/contrast a little more, maybe with an example of how Svn is different (for the merge process, not the tracking).
Hi taleswapper, great question. The primary difference is that DVCS keeps track of each change individually, so it can tell what changes need to be applied and what have already been applied.
With SVN, you need to manually track whether a change has been applied. So when merging branches, you aren’t quite sure what revisions to start and end from, and whether you’ve already done it.
With a DVCS, you can just “pull” from a repository and be confident you are getting just the changes you need.
The actual merge command is pretty straightforward in SVN (svn merge -r5:6 http://path/to/branch), but again, you need to know what revisions to start and end from, and whether it’s been applied.
[…] Mercurial for Distributed Source Control Posted in 1 by js0n on April 15th, 2008 A friend of mine turned me on to the distributed version control system Mercurial. It looks pretty awesome; the main selling point for me was the ability to host a source repository in a decentralized fashion. I’ve found these links useful in my investigations: […]
[…] Of course, in the eyes of the open source world, any centralised repository system is strictly a bit ‘old skool’ now, even the popular Subversion. Distributed version control systems (DVCS) are all the rage now, and I can see why, since they most directly represent the open source development methodology. The idea is that there is no central repository (although in practice, there are bound to be those which are considered more authorative), and every developer is capable of synchronising / merging with every other developer in a peer-to-peer, ad-hoc fashion. Tools like Darcs, Git and Mercurial implement this methodology, and in theory, I love the idea. Certainly I can think of several cases where it would have been useful to allow third parties to synchronise with external repositories - say, a small ad-hoc subgroup trying out a new technique which may take some time before it’s ready for the central version but people need to collaborate on it, sometimes without the direct involvement of the central team. Also, improved context-aware branching and merging as supported by these tools would definitely be useful to me as in a number of cases, quite large patches can get out of date while lenghty testing goes on, increasing the chances of conflicts when finally applied. […]
Distributed Version Control…
?? ??..
[…] Bazaar and Mercurial look promising, because they are Distributed VCS’s instead of regular VCS’s like SourceSafe or Subversion. Branching is much easier in DVCS software. For an excellent explanation of the differences, look here. I’m really leaning towards Bazaar or Mercurial for that reason, especially at work, it would be nice to create branches and revisions on-the-fly. […]
[…] If you want more information of source control basics, Kalid Azad has a great introductory article here and a good distributed source control article here. Also I take no credit for the fancy source control diagrams, they are straight from the linked article. […]
[…] Distributed Source Code Management is the wave of the future, and I can’t say enough good about it. My prefered system is Mercurial (aka hg), which I got to know why working on the Xen project. While git is getting a lot more hype of late, I still think hg is easier to use, and an easier switch for people that know subversion. […]
A very good read… really gives a visual of the DVCS. You also cleared a few doubts that I had in mind regarding the DVCS implementation in a Enterprise Dev Arena. I have a few queries;
-
how do you make available the most latest, stable code.
-
Doesn’t having private dev copy with each developer, lead to a scenario wherein huge merges may be required due to the divergence.
-
Again making private changes, I think, is to some extent, depriving a community from the changes available.
Thanks again for the post.
Hi Kishore, those are great questions. I don’t have any experience managing DVCS projects, so I’m making a guess based on what I’ve read.
-
Latest code. One drawback with a distributed model is that there’s no central location. One alternative is to have a maintainer who pulls code from various contributors on some schedule.
-
Giant merges. Although giant merges may happen, they are easier than merging in centralized systems because changes are tracked better. But you’re right, unless there is some syncrhronization the code could diverge.
-
Yes, it’s hard for the community to see the changes since everyone has their own copy. Having a mainter put together a “central” release may help this too (everything else considered experimental).
Again, these are just guesses based on the descriptions I’ve seen. Some projects use a hybrid centralized/distributed model.
[…] 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. […]
Hi Kishore,
Though I do not manage any large dVCS repository, I am quite actively following related topics on the Emacs development lists.
Attempting to answer your questions:
1> There is ONE official repository from where the releases are made. It is up to the individual developers to convince the owner/maintainer to pull in their changes. There are sites that list developer repositories with a brief description. Someone wanting to try code not still in the official repository can pull changes from the developer repositories if they are published (mercurial has a stable and crew repositories)
2> Giant merges do not often happen (well it did happen twice recently on the Emacs branch - multi-tty and unicode). But, it would still suffer from the same fate as in a centralized VCS. If some developer had merged some of the changes, those merges are remembered and you do not have to solve them again in dVCS.
3> Each developer can publish his/her official latest repository in the published list. If they are not disciplined in keeping it up to date, the same can happen in centralized VCS if they just edit and never commit.
Overall, I would say you can do anything in dVCS that you can do in centralized VCS. dVCS is a super set.
Hi Dhruva, thanks for the detailed info!
Hmmm…I wonder if a polling system could work instead of a “maintainer” to make decisions for what get placed in the main trunk? Say have a control panel that lets you set up each user with a weighted vote (maybe you don’t want the new untested guy to have the same weight as the rest of the team who has been battle tested), and for setting the trigger for acceptance of new code into the main. Hmmmm…