Time to Leave Monotone Behind?

[John Bailey]

On 02/05/2011 12:49 AM, Richard Laager wrote:
<snip>
> I think the conversion script was taking 36 hours or so to run in full.
> An incremental run is (I'm just guessing) less than 4 hours. With some
> time for the cut-over, that means there's a freeze on branch commits for
> maybe 48 hours and a freeze on trunk commits for 12 hours.

The more I think about this the more I think I'd rather just put a 48-hour
freeze on all of mtn and forget about doing an incremental conversion.

>> I'd like all developers, CPW's, etc. to review the authormap and branchmap files
>> in my hg repository here:  http://hg.guifications.org/pidgin-mtn-conv-files/
> 
> While this should be obvious, it's the portion *after* the = that will
> be used. Also, if you make changes yourself, keep in mind that you might
> be listed multiple times.

The vast majority of developers have at least two authormap entries (I have
three, myself).  Those of you who had commit access during the CVS/SVN days may
have more.

> As a matter of policy, do we want developers to use @pidgin.im email
> addresses or their "main" addresses?

I'd prefer letting each developer choose which address to use.

> In terms of remaining work, besides the authormap.TODO file, I'd like to
> go through the history from after the SVN-to-Monotone conversion to
> identify patch authors.

We're going to find quite a few revisions that need fixing up in that respect.
I know I've committed a few without setting the author.

> Additionally, we have some author and changelog certs with bad UTF-8.
> The authors are getting cleaned up as part of the author mapping. The
> changelog certs have been identified, but John and I haven't done the
> grunt work of fixing them yet.

This is another item on my ever-growing TODO list.  What puzzles me here is that
these revisions don't blow up hg convert.  We had a revision with invalid UTF-8
in its changelog cert and that continually blew up the conversion.  This is
where I started with fixing up the changelog certs.

> In terms of remaining questions/issues, I have the following:
> 
> A) How do we want to handle converting local branches? I think the
>    answer is that people will have to re-run the migrate script on their
>    own computer. While that sucks, it's a one-time pain for very few
>    people. That said, do we know this works?

The script would need some adaptation for that purpose, as I'm going to try
splitting out im.pidgin.www and im.pidgin.web.old into separate mtn dbs so we
end up with different hg repos.  If someone runs a conversion without splitting
these branches out, their hg repo will end up with these branches, and when they
push to hg.pidgin.im, all those new revisions would be pushed.

This should be possible, though.  There may even be some magic argument to
convert to make it look only at a given branch for conversion.  If worst comes
to worst we can hack something together to dump the private branch out of mtn as
a series of patches and commit them individually into the hg repo.

> B) I think we need a plan for commit mails, repository serving, and bug
>    tracker integration in place before we cut-over to hg.

I can take the stuff from guifications.org for commit mails and ticket
auto-closures and adapt it for us.  I originally borrwed it from Adium.

For repository serving, my intention is to use mercurial-server on one of our
servers and hg+ssh for pushes.  All we need in this case is an ssh pubkey from
every person who gets write access.  We can control on (at least) a
per-repository level who has write access to what, so we could for example
restrict a translator such that (s)he can't create a new repo but can write to
an existing one.  There is a "root" permission level concept in mercurial-server
which gives full access to all repositories served, as well.  We would need to
determine who should have this permission, as "root" level users can also grant
access to other users through the use of an hgadmin repo.

For web viewing, hgweb can be set up pretty easily in Apache.  I have no idea
how difficult it will be in lighttpd.  Anonymous clones over http will work
through hgweb.  There is a trac plugin for hg, as well, but it's only for trac
integration.  Apparently if you use it with trac 0.12 it can support multiple
repositories.  I'm not sure about that, as we abandoned trac over at
guifications.org in favor of Redmine.

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/20110205/a4eda9d0/attachment.sig>