AccuRev (was "bazaar/mercurial meeting")

[Martin Pool]

On  2 Jun 2006, John Yates <jyates at netezza.com> wrote:

> Some may recall past posts where I have argued for an ability
> to define project policies (eg filename case rules) and then
> to have the system comply with / enforce those policies.  In
> the realm of branch policies AccuRev very much seems to have
> that kind of functionality.

Yes, being able to support these things is important; the goal is to
define the kind of hooks and underlying data needed to let people build
it.

> It was clear to me and all in attendance that, at least within
> a commercial software engineering organization, given a choice
> between support for distributed development and this integrated
> support for a community of branches we would all choose the
> latter.

Yes, we're thinking about this too.  For example I think a central
master repository with managed branches inside it may be a far more
comfortable model for many companies than the model of other distributed
vcs where code is always distributed across machines that can suffer
disk crashes, theft, etc.  Branch nicks to give some context of where
code came from beyond just the contents of the change also go towards
this.  

It's true that the core tool is important but getting good process on
top of it will take years more.  There are the in-house uses you
mention; there are uses for Ubuntu; there is building a process-policing
tool like Aegis on top of bzr.
 
> To what do the projects aspire?  Do they simply want to supplant
> CVS and SVN in distributed / open source efforts.  Or do their
> ambitions extend to hoping to win over large parts of commercial
> software development as well?  If the latter then it is worth
> contemplating what RCS capabilities will be most compelling /
> enticing to commercial shops.

bzr's primary focus is on open source development; improving open source
development processes is what Canonical cares most about.  However,
making it possible to support other modes of overlap is good for
the project, for users who want the same thing on different projects,
etc.

> One way to avoid the trap of which project "wins" is to postulate
> a new project with enough interesting work and unsolved problems
> to keep both groups engaged.  Perhaps a new effort could exhibit
> fewer overlapping mechanisms (or at least more clearly orthogonal
> concepts and terminology).

We're talking about it.  

-- 
Martin