Can DVCSs enforce a specific workflow?

Posted by dukeofgaming on Programmers See other posts from Programmers or by dukeofgaming
Published on 2012-09-19T16:18:46Z Indexed on 2012/09/19 21:49 UTC
Read the original article Hit count: 270

Filed under:
|
|
|
|

So, I have this little debate at work where some of my colleagues (which are actually in charge of administrating our Perforce instance) say that workflows are strictly a process thing, and that the tools that we use (in this case, the version control system) have no take on it. In otherwords, the point that they make is that workflows (and their execution) are tool-agnostic.

My take on this is that DVCSs are better at encouraging people in more flexible and well-defined ways, because of the inherent branching occurring in the background (anonymous branches), and that you can enforce workflows through the deployment model you establish (e.g. pull requests through repository management, dictator/liutenant roles with their machines setup as servers, etc.)

I think in CVCSs you have to enforce workflows through policies and policing, because there is only one way to share the code, while in DVCSs you just go with the flow based on the infrastructure/permissions that were setup for you.

Even when I have provided the earlier arguments, I'm still unable to fully convince them. Am I saying something the wrong way?, if not, what other arguments or examples do you think would be useful to convince them?

Edit: The main workflow we have been focusing on, because it makes sense to both sides is the Dictator/Lieutenants workflow:

Dictator/Lieutenants workflow

My argument for this particular workflow is that there is no pipeline in a CVCS (because there is just sharing work in a centralized way), whereas there is an actual pipeline in DVCSs depending on how you deploy read/write permissions.

Their argument is that this workflow can be done through branching, and while they do this in some projects (due to policy/policing) in other projects they forbid developers from creating branches.

© Programmers or respective owner

Related posts about git

Related posts about mercurial