What is the managment overhead of decentrilized version control?

[Jan Hudec]

On Tue, Jun 20, 2006 at 10:06:56 +0100, Ben Edwards (lists) 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.

Bazaar-NG is designed to handle both decentralized and centralized
workflow and it indeed does. For centralized workflow, that is when
there should be several people committing to the same branch, there
are severalsolutions (they were already mentioned in other reply, though
not compared):

 - Central branch where everyone can push:
 	This requires only a server area with permissions set so that
	all committers can write over sftp. Each developer uses push to
	put his changes there. Push is only allowed if the target does
	not contain any revisions that are not present in source, the
	developers merge from the central branch and then push the
	result back.
 - Central branch where everyone can push + checkouts:
 	bzr now supports checkouts, that simplify the above process.
	Checkouts only allow commit when they are up-to-date with the
	central branch and automatically push them back, exactly as
	checkouts eg. in subversion do. They can be either 'heavyweight'
	(keeping mirror of all the data) or 'lightweight' (always
	accessing the data on server).
 - Patch Queue Manager:
 	The patch queue manager accepts merge requests via mail or by
	uploading files to a spool directory (or anything that can
	result in file being put in a spool). It requires more setup
	than the above options, but it can be set to do arbitrary checks
	before committing the merge. So eg. if you practice test-driven
	development, it can be set to run the test-suite and abort the
	commit if it fails.

> >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.   

It is not a problem to set up a write access for several people. The
easiest way is probably using ssh key-based authentication. Also IIRC
bzr supports sgid repositories, that is if the repository is sgid, it
sets group write permission.

> Peoples thoughts on this would be good, it would be great if people
> could concentrate on this issue specifically, I am sure there are lots
> of more general pros/cons threads;).

Have you already read the wiki at http://bazaar-vcs.org?

Anyway:

 - Bzr has very good merging. It handles merging of renamed files well
   and it supports annotation-based merge algorithm, that can help in
   resolving complex merge cases. If we exclude subversion, which has
   next to no support for merges, neither svk (which is built on top of
   subversion), git nor mercurial handle renamed files well.
 - Very easy branching. Also temporary branches can be on the devloper's
   machines and don't need to clutter up the server space.
 - Local branches are useful if the developers sometimes need to work at
   customer's site. They can have the branch on their notebook or even a
   memory stick and they can access all relevant history and even record
   changes for integrating later.
 - No single point of failure. If developers keep up-to-date local
   branches, than if the server goes down, they can continue to work and
   even reconstruct the mainline on some other computer by branching
   from their local copies (in bzr revisions keep their identity across
   branchies, so branching produces identical copy).

perhaps someone can come up with more.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060620/220536da/attachment.pgp