multi-headed repo (was Re: new user questions)

[Matt Mackall]

On Fri, Jun 03, 2005 at 08:28:53AM +0200, Thomas Arendsen Hein wrote:
> First, I have a suggestion for naming all these branch types:
> 
> branch = what you get with 'hg branch' now.
> twig = branchlet inside a single repo.
> head = latest changeset in a twig.
> tip = head of a selected twig.

Hrm. Confusing.. I suspect just about all the names are going to
change by the time this is done.

I'm well into making multi-head work. So far I've done:

- revamped dircache into dirstate which tracks add, remove, merge,
  states, etc.
- added heads() to revlog
- added an hg heads command that shows all the current heads
- made the repo merge protocol/algorithm work with multiple heads
- pulled resolve code out of merge

And finally I'm working on revamping the resolve code so that you can
do a merge into your working directory.

Currently, I'm still using a concept of "tip" which is the last
version in the repo. This will be the last thing you committed or the
last thing that the person you pulled from committed. When you do a
resolve, this is the default thing to merge with, which should usually
make sense.

> So you need to be able to specify branch, twig and tag/revision,
> where every parameter is optional and defaults to current branch,
> tip's twig and head of the twig.
> 
> Does this sound feasible?

I'm not sure how "twigs" work, how you'd name them, etc. Every single
point in the revision history is a potential branching point and a
potential thing to merge from. The only things that stand out in the
graph are the nodes that have two parents (merge points), nodes that
have no children (the heads), and the head that was added most
recently (the tip).

I think ideally, most public repos _don't_ have multiple heads and you
have a separate repo per line of development instead. If you want to
maintain a release branch, you do something like 'hg pull mainline
release-5.0' and now you have a tree with only the history from
release-5.0 back to build on and none of the other branches that are
post-5.0. That way, when someone pulls from your new repo, they don't
get a bunch of extraneous new development branches.

-- 
Mathematics is the supreme nostalgia of our time.