[rfc] bzr-colo into core

[Martin Pool]

On 25 March 2011 18:01, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/25/2011 02:10 AM, Martin Pool wrote:
> ...
>
>>> I wish bzr can hardlink packs and indices while cloning repo locally.
>>> Actually we're at the better position here than hg: packs and indices are
>>> immutable, only pack-names should be different when you commit new stuff and
>>> clones diverge. Packing repo in one clone should not affect other clones I
>>> think, but maybe it's important to break links before moving old packs into
>>> obsolete area. And it should work on the Windows too (although Martin gz
>>> metioned some issues there).
>>
>>> Can we?
>>
>> We could do that.  I thought there was a bug for this already, but I
>> can't see one, so I filed <http://pad.lv/742183>.
>>
>> Martin
>>
>
> What did you think about my repository-reference idea (similar to
> BranchReference which we already have). There are reasons in hg that you
> don't want to share a repository (it always wants to collapse heads).
> There is very rarely a reason where you might want to hardlink a
> repository, but not actually share it in bzr.

I think that's a pretty good idea; you're probably right that it would
be easier to implement and it would be a nice fit.  In a way it's like
setting one branch stacked on another.

One point is that it makes it more dangerous to garbage-collect the
origin branch; but that is not something people tend to do often in
Bazaar, and the same kind of danger is already present with stacking.
We could make the referring branches add a note that they exist
(either a full url or just a flag.)

> It would actually be a way to get rid of shared repositories between
> colo workspaces, because this workspace could say "and I'm storing my
> data over here with the other one".
>
> Anyway, it feels like it fits better with the existing bzr model, but I
> understand that it *is* a new concept, and is not backwards compatible.

I agree it is more in the style of things we tend to do.  It could be
backwards compatible at least until you use the feature.

Martin