Time to Leave Monotone Behind?

[John Bailey]

I apologize in advance for the length of this message.

On 01/21/2011 11:02 PM, John Bailey wrote:
> This seems like an excellent point at which to summarize again:
> 
> Total votes in favor of hg: 9
>   * Developers: 6
>   * CPW's: 1
>   * Downstream Projects: 2
> 
> Total votes in favor of git: 3
>   * Developers: 3

This debate has dried up.  I think it's time to end it.  To update everyone, the
final votes (with two votes communicated to me off-list) are:

Total votes in favor of hg: 11
  * Developers: 7
  * CPW's: 2
  * Downstream Projects: 2

Total votes in favor of git: 5
  * Developers: 3
  * Downstream Projects: 1
  * Translators: 1 (this vote was communicated on the translators@ list)

I think it's safe to say hg won.  Does anyone disagree with this assessment or
object to declaring hg the winner at this point?

> Once we're clear on which tool we're going to switch to, we can hash out the
> specifics of the conversion (timeline, why I chose to convert in the way I did
> when faster methods are available, etc).

We really should discuss these points now.  Particularly the timeline--when do
we want to switch?  I assume the answer to that question is "as soon as
possible," but begs the question of whether we want to have a blackout on
monotone during the entire conversion process or allow commits right up until
we're ready to put hg live.

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/
Any corrections to authormap entries to reflect addresses you'd rather use
should be emailed to either Richard or myself, unless you have hg+ssh access to
guifications.org already, in which case you can simply commit it yourself.
Branch renaming should probably be discussed on-list.

Also, as promised I'll explain the choices I made for the hg conversion that
have influenced Richard's massive contributions thus far.  I chose to use hg's
'convert' extension to convert directly to hg.  I *could* have relatively easily
used monotone's 'git_export' command and piped it into the hg fast-import
extension, but I chose not to do so.  Using hg's convert, although slow, allows
us to do some history cleanup.  Yes, this is modifying our history, but in this
case it's for the better.

As many of you know, we have a number of revisions in our monotone history that
have multiple changelog certs.  I've been slowly reviewing these and carefully
merging them as best I can to reduce duplication and potential for loss.  (This
part could be done for a git conversion as well.)  As I mentioned previously in
this thread, I expanded upon Felipe's prior work on an author map to get
consistent author names across our entire history.  I've also patched the
convert extension to handle comment certs (which monotone's git_export does
already) and a new "committer" cert that's come in handy for Richard's extended
work.  Richard has gone on to take a partial map of our ancient SVN history and
use it to set author and committer certs on revisions where a developer
committed someone else's patch.  The idea here is that our history can now be
more accurate with respect to authorship.

One unfortunate note here is that hg doesn't directly support a revision whose
committer wasn't it's author, which I wasn't aware of until Richard pointed it
out.  Sure, we can use 'hg commit -u SomeUserName', but there is no revision
metadata that says which one of us actually committed the revision.  Since no
such concept exists in hg to map to, the behavior I've patched into the convert
extension adds the committer cert's value to the converted changelog entry.
This is consistent with convert's behavior with git conversions and is supported
by some tools, such as hgk.

To get equivalent behavior out of monotone's git_export command, I'd also have
needed to implement a patch.  It would have been more difficult to patch
monotone's C++ code for the git fast-export stuff than it was to patch convert's
python code.

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/20110204/62804739/attachment.sig>