Time to Leave Monotone Behind?

[John Bailey]

On 01/18/2011 02:45 PM, Sadrul Habib Chowdhury wrote:
> I am mostly OK with any choice, mtn/hg/git. I am currently familiar
> with mtn/git, and it doesn't appear learning hg will be too much of a
> trouble. I have some personal branches in mtn, and a script for
> migrating those into corresponding hg branches would be useful for me
> (I suspect for other folks as well).

You'll find hg very familiar since you're already familiar with both mtn and
git.  There are a few oddities here and there, but that comes with the territory
of changing tools.  Mainly it's just remembering to type the right command--I
often still find myself typing 'mtn' in my own hg trees.  I've found it helpful
to use a few extensions, too.

You *should* be able to just use 'hg convert' without any special patches to do
that.  The convert extension should analyze your mtn database and determine what
revs need to be converted, then do the conversion.  Of course, you'd need to use
the branchmap and authormap files from the repo I linked at the start of this
thread so that the appropriate mappings happen.  Otherwise you could end up
duplicating a ton of history.

> I am curious about the 'subrepo' thing. Would it allow someone to
> checkout only libpurple, for example? Can subrepos depend on each
> other (e.g. subrepo 'finch' depends on 'libgnt' and 'libpurple'
> subrepos, so that checking out 'finch' also automatically checks out
> 'libgnt' and 'libpurple' etc.)?

The subrepo extension will recurse, to some extent.  It's all handled in a
versioned .hgsub file in each repo.  In a subrepo setup you might have something
like this:

finch
libgnt
libpurple
pidgin
TopLevelRepo
 |-- libpurple
 |-- finch
 |    `-- libgnt
 |-- pidgin
 `-- po

In this case TopLevelRepo would reference libpurple, finch, pidgin, and po in
its .hgsub file.  The finch repo would reference libgnt in its .hgsub.  When you
check out TopLevelRepo, then update along a branch (say, default), hg will pull
and update to specified revisions of the subrepos.  (One thing I didn't realize
until tonight is that subrepos don't automatically update--you have to update to
a newer rev on the subrepo then commit on the parent repo to update the ref.)

Now, we *could* arrange things like this:

libgnt
libpurple
finch
 |-- libgnt
 |-- libpurple
 `-- po
pidgin
 |-- libpurple
 `-- po
po

In this case, obviously there wouldn't be an all-encompassing top-level repo to
contend with, but the other pitfalls still apply.

Splitting out the tree into multiple repos and stitching them together as
subrepos would almost necessitate that we leave our history behind and start
with fresh repos.  Otherwise, we'd end up with five repos that are each 215 MB,
thus being far *worse* than our existing mtn setup.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20110119/5a227bdc/attachment.sig>