Before going on, I should mention that a lot of people see an SCM as
what it isn't: A way of resolving conflicts and allowing anyone to
make any commits they desire. What it actually is is just a way of
keeping versions of files or changelists, depending on its nature.
Say Company A has 5 projects, and has a central SCM repository. This
doesn't make any sense. Everyone is hitting the same box or cluster,
which would probably have to be geographically close. If you need to
take it down for maintenance, everyone's productivity is affected
With the distributed model, the central repository is still there, but
project A is able to have its own SCM node, and changes to that (in
our example) should not very much coincide with project B. These days,
it's easy enough to auto-integrate changes into another branch, so
integrating changes for the node for project A into the central
repository shouldn't require human intervention (apart from
unresolvable conflicts, which in theory shouldn't happen, since teams
should have effective communication on changes to things that
This means that teams that are distributed gaographically can have
their own local SCM service (this can make a big difference in terms
of productivity and developer happiness), and if any one node dies,
all it does is delay the mesh of code integration to and from that
node for a while.
On Sat, 12 Mar 2005 10:47:24 +0000, Bryan O'Donoghue <typedef at eircom.net> wrote:
> What is the deal with decentralised SCM being the holy grail of source
>> Ie, I'm sure darcs/monotone/arch provide better/more intelligent
> features then cvs... but... what I don't quite grasp (having not used a
> decentralised SCM, but, being in a position where I can effectively
> cherry pick my SCM), is how, I would reasonably synchronise say, four
> developers, distributed-source trees, into a release build on a "release
> build box"?
>> Would it be the case that _I_ would have to ssh into this box, and then
> pull a darcs/monotone/arch tree from all my developers... and then
> synchronise the conflicts by hand?
>> If so, then I think that distributed SCM is a _reterograde_ step from
> centralised SCM... even though it's new and shiny and popular... and
> only a heretic would speakeath against what's new and shiny and popular.
>> Or is it the case that I just don't "get" how the distributed model
> works in this case and if so, can someone explain to me, how, for
> example I would do a "release build" on a central server somewhere, for
> when we wanted to do a firmware release, and there were ... say 2 to 4
> different versions of the decentralised source repository floating around ?
>> Would I have to have a cron setup on the server, to incrementally 'pull'
> changes from the decentralised repositories, into the server, from all
> 2/4 developers... and if so... what the hell would happen with diff
> conflicts ? I'm sure this is a very _obvious_ question to those who have
> used the above tools... but, before I go spending hours find this out
> the hard way... does anyone on ILUG have definitive answers here ?
> Irish Linux Users' Group
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!