Re: Emacs Bazaar repository

[Juanma Barranquero]

On Wed, Mar 19, 2008 at 3:04 PM, Bastien <address@hidden> wrote:

>  They are not equivalent in terms of performance, but I think the
>  assumption was more precisely that all dVCS are equivalent in terms of
>  their ability to adapt to any workflow.  This assumption is true IMO.

Performance often influences workflow.

Also, that every dVCS is flexible enough to adapt does not mean that
all workflows are equally practical or easy to follow with any of
them. Were this not the Emacs project, determining the workflow and
choosing the tool that best matches it would seem preferable to trying
to shoehorn this or that tool to the desired workflow.

>  One of the benefits of using a dVCS is that you can envision different
>  workflows.  If everybody were okay with bzr then there would be no point
>  in trying to imagine other workflows before using the new dVCS.  But
>  since bzr has some annoying shortcomings, maybe it is useful to be sure
>  that everyone wants to stick to the current workflow before avoiding bzr
>  because of its inability to preserve this workflow...

I don't think we're at that point yet. We're at the point were normal
operations are slow because of the Emacs' repository size and long
history. At least, that's what it seems from the comments so far.

>  One of the shortcomings of the current workflow is this one: some piece
>  of code in Emacs is actively developped outside of the Emacs CVS (Gnus,
>  ERC, Org, etc.)  Since these pieces are also part of Emacs, any change
>  on them in the Emacs CVS requires someone to report the changes in the
>  local, independant repository of the module.  This is double work, and
>  such energy could be spared with the "Lieutenant" topology previously
>  described.

Agreed. But there are relatively few, very specific parts of Emacs
that suffer this problem: gnus, org, etc.

>  I propose to think about what a _distributed_ VCS
>  would be really useful for as a collective tool, in hope that such a
>  discussion might give directions in the evaluation of bzr.

That kind of discussion should be independent of the tool, shouldn't it?

 Juanma