On Thu, Oct 28, 2010 at 7:34 AM, Michael Foord <fuzzy...@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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
