Mirror trunk

[Stephen J. Turnbull]

Ivan Metzlar writes:

 > at my company we are currently discussing the importance of a local
 > mirror.

 > Still I can't find anything on the web explaining why 1 local
 > mirror is better/less complex than using multiple (upstream)
 > branches for each feature or bug. The only pattern I recognize is
 > that centralized verion control fans don't use a local mirror and
 > decentralized version control fans do. Why is it considered best
 > practice to use a local mirror? It seems like more work for the
 > same result....?

The simple answer is that (in Bazaar practice) *both* are considered
best practices, applicable in different cases.[1]

There are projects whose flow of changes is so demanding that it's
really important to have a buffer between you and the mainstream (the
Linux project is the most well-known example).  The local mirror
provides that.  There are jobs which involve much time disconnected,
and it's essential to have a cache.  The local mirror provides that.
When these characteristics dominate, the local mirror workflow is
"the" best practice.

OTOH, there are projects where work is divided so that you and your
colleagues are always "stepping on each other's feet" and continuous
communication is essential.  The branch from central workflow provides
a basis for that.

It sounds to me like neither character dominates your project(s), so
either workflow will work.


Footnotes: 
[1]  git and Mercurial essentially enforce the local mirror.