Re: Emacs Bazaar repository

[Thomas Lord]

Stefan Monnier wrote:
> Even if we end up using this tree to generate the initial Bzr tree, I'd
> be interested to know who to add merge info to a Bzr repository.
>
>   


This is a frustrating development, from my perspective.

Arch was designed to *not* be monolithic, in some specific
ways that are relevant to problems like this:

Arch defines a "global name-space" for projects, branches,
and revisions -- but the idea is that you can use that name-space
without using all of Arch.   Users disliked a few superficial
attributes of the Arch name-space but the basic idea of
having one is sound.   Without picking a specific DVCS,
one can still pick a distributed, global name-space for revisions.

Arch records merge history in the source tree itself, using
ordinary files, referring to that global name-space.   The
source tree, not some external database, tells you what has
been merged into a given revision.  So, again,
you can use Arch's way of recording merge history even if
you don't use Arch itself.   In practice, it's like having a
Changelog but an extra-fancy changelog that tells you
(or the merge tools you use) the merge history.   All that the
underlying DVCS has to do is make it possible to look up
various trees (or deltas between them) using the global names.

If you start with those two things, global names for
revisions and in-tree merge-history, then your perspective
on distributed revision control should change completely.

For example, merge operations need not any longer be
some built-in facility of the revision control system.  Rather,
merge operations are, by definition, algorithms that do some
diffing and patching by looking at in-tree merge history
and comparing various trees that are named there.   A merge
operator can be coded abstractly, in a way that works
across multiple revision control systems.

If a project like emacs, instead of picking a DVCS, picks
a naming convention for revisions and a representation
convention for merge history, then portability between
DVCS systems becomes a largely moot issue.

-t