[Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Brett Cannon]

On Thu, Jul 1, 2010 at 07:31, R. David Murray <rdmurray at bitdance.com> wrote:
> On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>> On Thu, Jul 1, 2010 at 14:52, anatoly techtonik <techtonik at gmail.com> wrote:
>> > Primary concern is that will happen with central Subversion
>> > repository. There are a plenty of private tools and automated scripts
>> > that were written to work with central Subversion repository, so it is
>> > important that central Subversion repository continue to operate and
>> > be synchronized.
>> >
>> > However, PEP 385 "The Future of Subversion" [1] does not propose any
>> > way to keep Subversion repository in sync. "it will probably live on
>> > for a bit" phrase looks like Subversion will be immediately dead after
>> > switching.
>>
>> It would certainly be possible to have snapshots of the hg repo be
>> committed into SVN, but I think people will actually notice sooner
>> that it's dead if we don't update it at all anymore.
>
> I remember the decision as being that SVN would be read-only after the
> switch.  Which will cause some pain, yes, but probably not as much
> pain as trying to keep both workflows available would.
>
>> > The second concern is workflow. Even after getting my hands dirty I
>> > still can't find the best solution for working with Mercurial copy of
>> > Python.
>>
>> Mercurial is relatively flexible in that there are lots of ways you
>> can do this, and so I find that, certainly for the local parts of the
>> workflow (e.g. those that don't directly affect the repo that everyone
>> sees), I don't want to mandate a certain workflow. On the other hand,
>
> And this is the reason that Martin says that a *working* (final
> configuration) repo must be available for some time before the transition
> takes place, so that we can all experiment and figure out what external
> workflow is needed, and document what people find to be useful internal
> workflows.
>
> I think someone needs to say, "OK, what's up is how it is going to be,
> you've got X weeks to make sure you can work with it and then we cut
> over" before the balance of the dev community is going to actually try
> working with it.  But one or more volunteers could make the first cut
> at the workflow docs right now, I would think, and that would be a big
> help for this process
>
> I know I would have preferred to have such docs before I gave it a
> try...but I need to be able to talk intelligently about HG at PyOhio,
> so I need to start learning it this week.

Here is a *really* quick-and-dirty approach for non-committers to
create a patch they can submit. This is not extensively tested so some
other Hg expert should back me up on this before telling anyone that
this is the simplest way. I am also not saying this is how we will
want people to contribute in the long run, but this does work and
matches how svn does things well enough that people shouldn't get
thrown by the details.

1. Contributor clones the repo
2. Contributor makes changes, committing as they go
3. Contributor runs ``hg outgoing --patch --git > patch.diff``
4. Committer runs ``hg patch --no-commit patch.diff``
5. Committer does the usual review->commit thing

Basically this creates git-style diffs that one can shuttle around. I
think you can also use ``patch -p1`` or git-apply to apply the patch
generated by Mercurial.

The other option is using mq (Mercurial Queues), but I personally have
not gotten around to learning how to use them so I can't tell you any
details. But if the Hg transition is taking too long for you, mq can
be used on top of svn w/o issue:
http://mercurial.selenic.com/wiki/WorkingWithSubversion#With_MQ_only .

This obviously does not cover how committers should backport. That
will very between whether it is within 3.x or 3.x to 2.x (or
vice-versa). That will require a bit more thought and discussion.

And finally, http://hginit.com/ is one of the best Hg intros I have
come across for explaining fundamentals.