I have really tried to understand how distributed version control systems alter the way we work. I watched a tech talk of Linus Torvalds on git, which is mostly about the power of distributed version control, and he claims that it alters the way in which we work.
Let’s consider git. There are plenty of good reasons to love and use git, I am aware of these good reasons. I am also certain that the power of the decentralised model doesn’t extend to just efficiency and the ability to make local commits. One of the important points is that it allows developers to synchronise their work. Assuming that the work has not been commited already, I would presume the code to be (potentially) unsuitable for deployment, possibly subject to change (bad if I am hard coupling my dependencies to it), which to me sounds like a world of pain waiting to unfold.
I have a feeling that the decentralised model works brilliantly in the setup that Linus faces, but this is typically uncommon of most setups or needs, and that a centralised setup is essentially what we all want and use within our unified networks (i.e. the majority of company setups, though I admit this is an assumption on my part). We all push stuff back to a central location so we can share it with others, and this need for centralisation forms the basis of github. We all rely on the integrity of the central location to provide secure access to our work and to back it up for us as well.
Don’t regress into answering why git is lovely. It works brilliantly in a centralised model with the bonus of local commits, but I really feel like I have missed the point about decentralised workflows somewhere…. I may have to watch the video again
Update:
Thanks for engaging the question, I don’t think I made my point particularly obvious. Basically the issue I face is as follows. Many companies are setup with a central workflow. We work on a unified fast local network. Managing the logistics of a centrally managed configuration are somewhat simpler; we all use the central repository, this is the honey pot we make sure to safeguard against disk failures and fires and anything else you might be paranoid about. Factoring this necessity into your workflow increases the chances that your work, regardless of state, ends up in this safe location. We rely on the network connectivity and availability of this central location for just about everything we share. I first thought that maybe that our love for the central workflow is just our inability to grasp how to use DVCS on the micro scale. Now to say just use git because it’s a superset of the centralised variant is ok I guess. However given that I still, in the majority of cases, can’t see anything that is intrinsic to the decentralised model, we might be using a more complicated tool to solve a simpler problem. There may be some value in a centralised tool that does what we are already doing.
I’ll try to answer on asked question
Sort version
Any DVCS does NOT improve workflow by itself. So on question “How?” fast&simple answer is “In no way!”
Longer version
DVCSes have possibilities (due to distributed nature), which can be used to change and evolution workflow and common style of work. But it’s always not technical, but managerial, administrative and organizational solution and responsibility: what, how, when, to solve which business-tasks using DVCS is possible and justified.
Immediately at the start I can see one big business advantage of DVCS – it allow P2P communication between developers, decreasing this way wasted in CVCS mode time.
Where it can be useful and requested? Any time, when 2+ developers work on related, but isolated from “mainstream” task. Imagine
SVN-version, branch-per-operation mode
DVCS-version
Story is not dramatically shorter and differ in 1 place – when coredev have his finished job, branch delivered to frontman, merged locally. Later merged work can be branched-cleaned-stripped into ready to publish for public form (cherry-picking, history rewrite etc)