When working remotely, our team only has access to our source code by remote desktop into our office PCs so we never really work in offline mode. Does a distributed version control system like Mercurial or Git still give us advantages over our current centralized Subversion set up? If so, what are they? Are there any drawbacks or pitfalls? I've read in numerous places that shifting to distributed version control requires a change in thinking. Can someone explain what needs to change in this regard?
views:
151answers:
3
+1
A:
As explained in the differences between DVCS and CVCS (Centralized VCS), the main advantages are:
- local commits (you can commit more often in private branches, then clean up the history you want to push to other repos)
- publication process (you pull from multiple repos, or quickly established intermediate repos to push to, where you can do intermediate tasks like continuous integration tests)
That last point required the most "change in thinking" and is a bit scary ("I can pull from any repo?!")
But once you realize the benefits, you can really have more productive development cycles because you are able to monitor (by fetching commits from your peers) the development of some of your colleagues. If they are developing a function that you need, you can start integrating it sooner.
(The thing to remember with a DVCS is that is doesn't prevent the setup of a "central" repo, for other developers to pull from)
As for continuous integration, instead of pushing directly from your repo to a central server in charge of CI, you can push to a local repo on your desktop, which will run all the tests, before pushing automatically (if "green") the code to a "central" repo.
It is so effective that you can now push to the official central repo a code that "never breaks the build", rendering your CI server pretty much useless ;)
VonC
2010-06-01 04:13:24
Thanks. The points about easier integration and improvements to continuous integration were exactly what I was looking for.
Luke CK
2010-06-02 04:17:26
A:
The development machines might stand next to each other, but the source code is still distributed between them. That the machines are in close physical proximity really doesn't matter for managing source code changes made by different developers.
sth
2010-06-01 11:03:43
What I was getting at is that none of the developers on our team ever work offline. The ability to commit to a local repository when offline is one feature of distributed VCSs that is often mentioned as one of their advantages. I asked the question to try to find out if this feature is still useful to us and if the other features of a DVCS would make it worthwhile for us to switch from Subversion.
Luke CK
2010-06-02 04:14:57
+1
A:
I would recommend HgInit as a very thorough explanation of just how svn is improved upon by a decentralized toolset. It will also help you to understand the conceptual differences.
One of the big improvements I'd like to emphasize is the notion of merge tracking. Subversion didn't have this feature at all until 1.5, and with the difference in the way it treats revisions and branches, it will probably never be as good as the decentralized tools can be. Nobody likes merges. Might as well reduce as much of that pain as you can. Also see: http://stackoverflow.com/questions/43995/why-is-branching-and-merging-easier-in-mercurial-than-in-subversion.
The biggest change in thinking for me when making the switch from subversion was getting over the idea that history is strictly linear, and branching is nothing but copying code to another directory. Note that in Git and Mercurial, you don't checkout a subdirectory of the repository. You won't see 'git checkout http://github.com/project/branches/v2.0' or anything. Eric Sink wrote a really good explanation of the difference in the way the history is stored. I recommend taking a look.