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

[Tristan Zajonc]

While both hg and git are fine, I'd vote for git so that we are using the
same DVCS as IronRuby, the DLR, and Mono.  GitHub also provides excellent
community features and is larger than bitbucket.

Obviously Michael's and Jeff's opinion probably matter most.  I'd suggest
just making the call and sticking to it.

On Thu, Oct 28, 2010 at 2:16 PM, Vernon Cole <vernondcole at gmail.com> wrote:

>
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20101028/390aa156/attachment.html>