What is the managment overhead of decentrilized version control?

Brian M. Carlson sandals at crustytoothpaste.ath.cx
Tue Jun 20 10:40:20 BST 2006


On Tue, Jun 20, 2006 at 10:06:56AM +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.

Just as a note: using a decentralized system has the great benefit of
reducing the possibility of failure.  Say your server crashes at the
most inconvenient time possible.  Everyone should still have their own
branches on their own machines, so all you really have to do is find a
temporary machine that people can read to and write from, and you're up
and running again.  Even if you can't do that, people could still work
on their own tasks.

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

Have you considered making that "someone" into a "something"?  The
bazaar-ng project uses a patch queue manager (PQM).  Basically, AIUI,
certain developers (those who are allowed to update the master) send a
digitally signed message to the PQM, which then merges.  If the merge
fails, nothing happens to the branch, and the person requesting the
merge gets an error message.

If you don't want to use a PQM, you could have each person who is
allowed to merge have a checkout of the mainline, and then if they want
to merge, they just do it.  Due to the nature of checkouts, you cannot
commit (except locally, and even then only on a heavyweight checkout) to
an out-of-date checkout.  Therefore, people who wanted to commit would
be obligated to keep their checkout of mainline up-to-date.

As far as low-tech solutions, you could have a patch pumpkin.  It
wouldn't even necessarily need to be assigned to a given person at a
time.  Simply have the pumpkin out in a common area, and require it to
commit on mainline.  This could, however, be undesirable if your
employees are wont to fight each other over the possession of the patch
pumpkin.  How to solve *that* problem is left as an exercise to the
reader. ;-)

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_}<DATA>;eval$a;print;__DATA__
M961H<F$@8FAM;"!U<F%O<G-U(#QU<F%O<G-U0&=D:75M<&UC8VUL=G)U;6LN
M<FUL+F=Y/@H)>2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060620/632df79c/attachment.pgp 


More information about the bazaar mailing list