What is the managment overhead of decentrilized version control?

[Michael Ellerman]

On 6/20/06, Ben Edwards (lists) <lists at videonetwork.org> wrote:
> I am currently evaluating bazaar.  From our perspective decentralised
> version control is not really necessary, we are a software house mainly
> developing Plone sites. From the perspective of a release manager I am
> trying to work out what the management overhead is for bazaar and
> decentralised version control in general and also what other benefits
> bazaar may have for a organisation not needing centralised version
> control.

Firstly, I think you should also be thinking about the benefits that
it will give your _developers_, after all they're the guys who do the
real work that pays the bills. So even if decentralisation entails
some more management overhead it may be worth it as you give your
developers better tools to do their job.

> From my understanding if you have say 3 developers working on a project
> for a release they would all push there changes to what has been agreed
> upon as the release branch and then someone has to merge the code in
> this branch.  The subversion method would be people committing there own
> work and doing the merge themselves.  Although this does mean they need
> write access to the master repository at least the person doing the
> merge understands the code.

Not really. The idea would be each developer has their own branch, and
they check code into it as they work. When they want to push their
changes to the release branch, they first do a merge into _their_
branch of the release branch. This brings down any new stuff in the
release branch and the developer merges _their_ changes. They then do
a push to the release branch.

But that's only one way to do it. The point is the DVCS are much more
flexible in the workflows they allow. With bzr you can even emulate
much of the SVN/CVS model if you think that's useful.

cheers