Time to Leave Monotone Behind?

[Mark Doliner]

On Sat, Feb 5, 2011 at 10:09 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> 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 think that's totally fine.  Whatever is the least amount of work for you.

>>> 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.

I have this line in authormap.TODO:
Mark Doliner <mark at kingant.net> = Mark Doliner <mark at kingant.net>

That can be moved to authormap and changed to:
Mark Doliner <mark at kingant.net> = Mark Doliner <markdoliner at pidgin.im>

>> 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.

+1

>> 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.

Another option might be to just force these people to push their stuff
to our main repo before the conversion.  Or force those people to deal
with the problem themselves.  I'm not one of those people and I'm
pretty cold-hearted, so maybe my vote shouldn't count for much :-)

>> 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.

Does hg have a standard way to do commit emails, repository serving
and bug tracker integration?  It seems like it should...?  It's not
clear to me what you would be borrowing from guifications.org.

> 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.

Does that mean we'd need to create a system-wide user account for each commiter?

--Mark