Repository collection practices

[Eric Hopper]

On Mon, Jun 26, 2006 at 05:22:23PM +0100, Mark White wrote:
> Out of interest: what kind of working practices do people have for
> organising their collections of Hg repositories (which, under eg
> Subversion, might live in a single tree?)

My working practice is to have a directory for each project, and then a
number of sub-directories, one for each branch I care about for some
reason.

Sometimes non-repository, project-related data is also put at the same
level as the branch sub-directories.

> And am I right in thinking that the revlog approach to hashing changes
> means Mercurial is fundamentally not geared to work with subtrees?
> (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?)

There are ways to make this work.  Mercurial changelog hases are based
on the changelog message and the manifest.  The manifest contains all
the hashes for the files.

This means that if you are willing to write some code to ignore the
parts of the manifest that aren't in the subtree you have, you can get
all the history associated with the files in the subtree and be able to
commit things to it without having to have the actual file data for any
other parts.  Mercurial can still maintain consistency and check that
your subtree is valid with regards to all the hashes it keeps.

Have fun (if at all possible),
-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.selenic.com/pipermail/mercurial/attachments/20060626/63a2568d/attachment.pgp