On Thu, Jul 1, 2010 at 07:31, R. David Murray <rdmurray@bitdance.com> wrote:
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik <techtonik@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.