[IronPython] The elephant in the room: source control for IronPython
vernondcole at gmail.com
Thu Oct 28 11:16:30 PDT 2010
On Thu, Oct 28, 2010 at 7:34 AM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:
> On 28/10/2010 03:53, Steve Dower wrote:
>> I'll add in a vote for Mercurial (voting always seems to be how to
>> decide on VCS), though I still believe that SVN works better for a
>> contribution/review/patch workflow.
> Distributed version control systems are very good for distributed
> development (funny that). Whilst I'm not proposing we use bzr (I would
> *very* much like us to use mercurial though), our workflow at Canonical with
> bzr and launchpad is great. You develop in a branch (branching is very easy
> with dcvs') and push to launchpad. On requesting a merge review you get a
> great web interface with viewable diff and when the merge is approved you
> merge back onto trunk. (Branching and merging are substantially easier with
> hg / bzr / git than with svn.)
> Having many outstanding branches waiting for review (and keeping them up to
> date) and starting new branches that depend on other branches is all very
> easy. Having infrastructure that allows us to easily store feature branches
> is important for that particular workflow.
> I agree completely. Right now on my *laptop*, I have 22 bazaar
repositories, one CVS, and 4 mercurial. Two of the latter are IPy specific:
ironpython.sqlite and adodbapi. PyWin32 will also be going to mercurial as
soon as Mark Hammond gets around to it. (If they ever get a Windows version
of bzr-hg working I won't even have to remember two slightly different
command sets.) The correct choice for the future is hg.
> Is the plan after 2.7 to start doing 3? That seems like a good
>> opportunity to "start fresh" in a new repository and leave the old
>> stuff where it is, only carrying over the barest minimum. I can't see
>> any movement before 2.7 as being worthwhile.
> Interesting question. Ideally we would do parallel development but I'm not
> sure we have the resources for that.
Python 2.7 is documented to be the LAST of its family. There should not be
very much "development", except perhaps filling out the standard library.
I would say to put 3.n on a fresh hg tree, and back-port anything necessary
into the existing 2.7 tree and infrastructure. No sense in re-inventing that
Much of the difficulty in converting 2.n Python in 3.n has to do with
converting between 8-byte strings and Unicode. Since IronPython is already
there, I anticipate that there will be minimal problems in 2to3. Parallel
development may be largely unnecessary. [Having a piece of published code
which runs on all three platforms (2.n, IPy & 3.n with only one trunk
version - no branches), I think I can speak with some authority.]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users