[rfc] bzr-colo into core

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> 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?

Actually, there are some very fundamental differences. A revision only
ever belongs to a single named-branch. Ever. You can't pull the last
revision in "default" to be the tip of "issue123".

(so you don't really have 'mirror branches' as we call them. You just
get a local named branch that matches the remote named branch.)

If you pull someone who has a named branch that matches your own named
branch, you just get a "+1 heads" warning. Telling you that your local
branch has multiple heads. For example:

upstream
default: [A] --- [B]

my repo
default: [A] --- [B] --- [C]

your repo
default: [A] --- [B] --- [D]

After I 'pull' your repo
default: [A] --- [B] --- [C]
                    \--- [D] #still on "default"

That is, I believe, how 'hg merge' knows what revisions to merge. By
default it merges all of the extra heads in the named branch you are
currently working on.


There are other oddities that stem from this. To *create* a branch, you
have to commit (since otherwise the tip of the branch would be a
revision on another branch).

To determine what the current branch tips are, I believe Mercurial
actually walks the DAG. I *think* it stores the [A] revision in its
branch file, which never changes. All children of that revision which
are heads (not in another branch) are considered to be the tips of that
name.
I don't really know how this scales when you have an Emacs branch with
100k revisions on "default". As such, they might do something different
to track more-recent revisions. They might even update the branch file
on every commit, and just sometimes store multiple values there for a
given branch name.

That is just what I know of off-hand, for some very real differences
between what Mercurial considers a "named branch" and what bazaar thinks
of as a "Branch".

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2LHOkACgkQJdeBCYSNAAPzwACgq6WQk4RezOi6Iv5zV9GSz/y5
iVYAnjPBvhYU4PJihIudalgb82Uh3J7c
=odyK
-----END PGP SIGNATURE-----