On Mon, 21 Mar 2011 03:44:34 +0900, "Stephen J. Turnbull" <step...@xemacs.org> 
wrote:
> I'm coming to the conclusion that those who say that Mercurial
> documentation should be found at the Mercurial project are wrong.  I

+1.  I think the dev docs should explain anything needed to do the
basic Python workflow, even if that feels like repeating parts of the
Mercurial docs.  (If it is a large chunk, then a pointer to the exactly
relevant section of the Mercurial docs would be appropriate.)  On the
other hand, I'm not offering to do the work, so I'll happily accept
what has been produced so far (thanks, Antoine!).

> think there's a reasonably strong case (based on the explicit promise
> of PEP 0374 that workflows would change as little as possible) for a
> follow-on informational PEP providing verbal, and maybe automated,
> scripts for the various operations needed in the Python workflow.

Sounds good, but someone needs to write them.  You'll note that I've been
asking for this for a while, but as it turns out it wasn't really possible
to write them "correctly" until we started actually using the system.
I'm still not comfortable enough to write them myself, but after I've
used my chosen workflow for a while I'll do my best to write it up in
more detail than my earlier post as a blog post or something.

> OTOH, people who are having problems with the workflow imposed by
> Mercurial need to recognize that Subversion basically ripped a big
> hole in the QA aspect of Python's workflow.  As Nick points out,
> Subversion merges create new versions in the repository that *never
> existed in any developer's workspace* and therefore was never tested
> before committing.  This is somewhat mitigated by buildbot testing,
> but that is mostly unit testing and inherently is not very good at
> catching problems due to interactions across modules.  That is, it's
> not that Subversion provided a simpler way of doing the work.  Rather,
> it hid the fact that certain work was not being done at all.  hg
> exposes this fact.

Given that I generally did an svn up and a final regrtest run before
committing in SVN, the hole here for me was small (whatever changesets
came in after my up and before my commit).  Given that I do an hg pull/up
and a final regrtest run before starting my merge dance and am unlikely
to *re*run the regrtest after having to do an hg pull/merge heads,
exactly the same size hole is going to exist in my hg workflow.

--
R. David Murray           http://www.bitdance.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to