What is the managment overhead of decentrilized version control?

Matthew D. Fuller fullermd at over-yonder.net
Tue Jun 20 11:03:06 BST 2006


On Tue, Jun 20, 2006 at 10:06:56AM +0100 I heard the voice of
Ben Edwards (lists), and lo! it spake thus:
>
> I am currently evaluating bazaar.  From our perspective
> decentralised version control is not really necessary, we are a
> software house mainly developing Plone sites.

One thing to take note of is that bzr DOES have it as a goal to
support the centralized workflow as well as the decentralized.


> and also what other benefits bazaar may have for a organisation not
> needing centralised version control.

I think the ABILITY to work decentralized is a nice bonus, even when
you're generally working centralized.  And more, the capabilities
(like the branching and smarter merging) that are absolutely necessary
for DVCS's are also very useful even when you're working centralized;
branches for experimentation or disruptive features are nice, and
being able to easily merge them around turns them into usable tools
instead of the vicious teases they are in e.g. CVS.


There are a lot of steps between a full-mesh ultra-distributed setup
(where everybody has their own branch and they all merge back and
forth from each other) which DVCS's are designed to handle, and a
single-branch fully-centralized setup (where there is no branch but
the one branch, and everyone commits right to it) that CVCS's staked
out.  The hope is that bzr will work anywhere along that spectrum.

Consider one intermediate case, for instance: There is one centralized
branch, that is the "official" branch.  Every developer has a checkout
of that branch.  Every developer also has their personal branch, which
they work in.  Whenever a developer finishes a self-contained "piece",
whether that's 1 commit or 50 commits in "their" branch, they merge
that over and commit it to the "official" branch.  The workflow then
is very close to what you'd get in a CVCS, except that people tend to
make more individual commits of smaller pieces (in their branch),
rather than grouping larger things into a single commit in the main
branch.


Me, I favor generally centralized layouts.  In the projects and team
dynamics I work on, it's not just that centralized workflow "works",
but it works really really well, and there's no desire or NEED to
change it.  There's no need for a dozen branches, and people
cross-merging, and blah blah blah; a single mainline that everyone
commits to really does work.  In that case, having the OPTION to
branch and merge for larger changes, or disconnected operation, or
other things, is a really big bonus that I'm giddy to have, even
though 75% or 90% or 99% of the time it's not used.


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.




More information about the bazaar mailing list