[rfc] bzr-colo into core

[Martin Geisler]

Martin Pool <mbp at canonical.com> writes:

> On 24 March 2011 20:16, Martin Geisler <mg at aragost.com> wrote:
>> Martin Pool <mbp at canonical.com> writes:
>>
>>> {summary}
>>>
>>> Let's make bzr-colo the default model for bzr 3.0 in September.
>>>
>>>
>>> {the problem}
>>>
>>> At the moment there are various different ways to use bzr: checkouts
>>> from a separate repository directory; bzr-colo; checkouts with local
>>> commits; standalone branches. This gives users some flexibility but
>>> it also makes some things confusing, and it's easy for people to end
>>> up with a setup that's quirky, or that doesn't work well for them.
>>
>> This might be totally irrelevant for your discussion, but as a
>> Mercurial developer, I was wondering if you have looked at how
>> Mercurial supports multiple branches in a single repository?
>
> Hi, Martin (there's a lot of us around),

Heh, yeah :) I was always "Martin G" in school...

> I have looked a bit at how Mercurial does it. Thanks for explaining
> it.
>
> The repository and branch breakdown is fairly similar; bzr too has a
> DAG that is pointed to by branch tips. One difference is that I
> believe hg generally hardlinks repository-internal files when you make
> new repositories on the same disk, whereas bzr copies, and rather
> wants to avoid having multiple repositories unless you really want
> them to be separate.

Yes, Mercurial makes hardlinks when you clone on the same disk. This is
in principle just for efficiency, and does not affect the underlying
model. The hardlinks are broken on a per-file basis when you make
commits that touch a given file and so the two clones appear to be
really independent.

> The situation you describe there is pretty much what bzr-colo gives
> you.  The main issue that comes out of this thread seems to be that
> people like having multiple working trees all addressing branches
> within the same repository: either creating and deleting those trees
> as needed, or switching a small number of trees among several
> branches.
>
> I guess in hg you would do this by having a repository for each
> interesting tree, and pushing/pulling between them?

Yes, that is how it's done. For me, the major "aha!" moment was when I
realized that it makes no fundamental (conceptual) difference if you
have a single clone for all your changesets or several clones.

It might be practical to have two clones on disk, one for a stable
branch with bugfixes, and one for new feature development:

  $ cd stable         # working copy is at most recent stable changeset
  ... fix critical bug
  $ hg commit
  $ cd ../default     # working copy is at most recent default changeset
  $ hg pull ../stable
  $ hg merge

or you can do it in one repository:

  $ cd repo
  $ hg update stable  # working copy is at most recent stable changeset
  ... fix critical bug
  $ hg commit
  $ hg update default # working copy is at most recent default changeset
  $ hg merge stable

In the end, it is all one big DAG.


-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/