[IronPython] The elephant in the room: source control for IronPython

[Vernon Cole]

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
wheel.

 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.]
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20101028/0343ce1c/attachment.html>