Repository collection practices

[Bryan O'Sullivan]

On Mon, 2006-06-26 at 17:22 +0100, Mark White wrote:

> And am I right in thinking that the revlog approach to
> hashing changes means Mercurial is fundamentally not geared
> to work with subtrees?

It isn't geared to work that way at the moment, at any rate.  This isn't
intrinsic to revlogs; it's how Mercurial computes the identity of a
changeset.  I'm curious as to what use you'd see for the behaviour
you're asking about.  I gather this is something that Arch supports, but
I've never needed it myself, so I've not given it any real thought.

> (In other words: is it feasible that
> "hg clone" could work on part of the tree one day, without
> breaking the ability to push/pull between clone and parent?)

No, that would require a redesign.

You can get partway there right now, though.  It's possible to merge two
"unrelated" trees, foo and bar:

        hg clone .../foo foobar
        cd foobar
        hg pull -f .../bar
        hg merge

The merged foobar tree can continue to pull changes from either foo or
bar after the merger, but it's typically no longer possible to push
changes from foobar back to foo or bar.

	<b