Re: [Python-Dev] Mercurial, linefeeds, and Visual Studio
2009/6/6 Mark Hammond : > Paul Moore wrote: >> >> 2009/6/5 Nick Coghlan : >>> >>> Dirkjan Ochtman wrote: > > Essentially, pcbuild.sln is a binary file, and should be treated as > such. Maybe it's an error in the Subversion setup that it's treated as > text at all... Yes, it certainly seems that way. >>> >>> Except it isn't a binary file - it's a text file with CRLF line endings. >>> Why would we throw away the chance to get meaningful diffs when >>> Subversion can easily get the line endings correct? >> >> Fair point - I hadn't thought of it in that context. I wonder if >> Mercurial can treat it as a specialised form of binary file with >> custom diff/merge behaviour (which just happens to be "treat as >> text")? Of course, if that also requires client-side configuration, >> it's no better solution than win32text. >> >> I've a feeling I've seen discussions of versioned metadata (things >> like file properties) in Mercurial at some point in the past, but my >> Google skills are failing me at the moment... > > I've looked into this recently. IIUC: > > * There has been some limited support expressed for having win32text look in > a normal versioned file for hints about the current repo. > > * Once concern here was the fact that such config files are somewhat > 'untrusted', but the hg config parsing code has recently been reimplemented > to support the concept of 'trusted' versus 'untrusted' options. I'm not > sure what this means in practice though. > > * There isn't currently much activity on win32text. None of the core hg > devs seem to use Windows, so while they are receptive to Windows patches, it > might be necessary to be quite noisy to get attention. > > I recently submitted some changes to the filtering for Windows which were > accepted without any angst, and the ability to use a versioned file for > per-repo rules is something I'd like too. I believe that if a few Windows > users got together and agreed on both semantics and implementation we could > get such an enhancement landed in the core of hg... I'm willing to help on this, but I don't personally use win32text (my approach is to have all files always in Unix line-ending format, which every tool I use handles fine). So take any design suggestions I might make with a pinch of salt :-) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP 385: Migrating from svn to Mercurial
Antoine Pitrou schrieb: > Dirkjan Ochtman ochtman.nl> writes: >> >> http://www.python.org/dev/peps/pep-0385/ > > « [cloned branches] makes it easier to distinguish branches, at the expense of > requiring more disk space on the client. » > > This is a bit misleading. Actually, by separating branches into distinct > repositories, you can save quite a bit of repository space. It really depends > on > the structure of the project and your own workflow. If you follow the "strict-subset" policy (which I would strongly recommend, from my experience) you'll end up with both branches in the trunk repo anyway. > « This reflects that the default branch in hg is called 'default' instead of > Subversion's 'trunk', and reflects the proposed new tag format. » > > If we use several distinct repositories, the default branch should instead > mirror the repository name (like what is done in the current hg mirrors: > "trunk", "py3k", etc.). +1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Roundup keywords for bug tracking
Daniel Diniz schrieb: > anatoly techtonik wrote: >> >> It is impossible to edit roundup keywords and this takes away the >> flexibility in selecting bugs related to a module/function/test or >> some other aspect of development. For example, I need to gather all >> subprocess bugs in one query and things that won't be fixed in >> deprecated os.popen() into another. In Trac I would use "subprocess" >> and "os.popen" keywords. On ohloh I would add similar tags (if bugs >> were software) without, but I can't do anything about Python roundup. >> Is there any reason for such restriction? > > Well, keywords are used as a very restricted set of tags, so only > users in the Developer group can create them. We've discussed free > form issue tags that any user can create or edit in #python-dev and > tracker-discuss[0]. I'm pretty sure they'd cover your use-case. I've > submitted a patch to Rietveld[1], but it seems I never filled it in > the meta-tracker, oopsie. > > If you (or anyone else) want to test-drive the tags feature, I can > create an account in the experimental tracker[2] (which needs some > attention anyway). I should be able to submit the patch to the > meta-tracker during the weekend. I'm not sure it will get well tested on the experimental tracker. If it basically works, and no one has any real objections, I'd just add it to the live tracker and try out how and if it is used. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Snakebite (was: Re: py3k buildbots)
On Fri, Jun 05, 2009 at 11:26:34AM +0200, Thomas Heller wrote: -> Antoine Pitrou schrieb: -> > Hello -> > -> > Only one of the py3k buildbots seems up: -> > http://www.python.org/dev/buildbot/3.x.stable/ -> -> Maybe they are waiting for the snakebite network ;-) (what's up with it, anyway?). We're still getting the machines set up. It turns out delivering power and A/C to a wide variety of architectures is more complicated than it may sound ;) --titus -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Status of 2.7 and 3.2
2.7 Once upon a time, the plan was to come out with 2.6 and 3.0, and then after the usual interval, 2.7 and 3.1. As it turned out, 3.0 came out 3 months after 2.6, but, as it typical of x.0 releases, had some flaws leading to 3.1 now just 6 month later. I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? Data: On the tracker, new features are being assigned to 2.7 and 3.2. PEP 373 Python 2.7 Release Schedule says zilch: Release Schedule: Not yet finalized Possible features for 2.7: Nothing here 3.2 At some point, 3.x will become the "trunk" branch. It seems to me that this should be done with 3.2 as part of the transition to Mercurial. A. As long as 2.x is 'trunk', some people will view 3.x as 'experimental'. That was true for 3.0, but (much?) less so for 3.1. Is there any known reason why 3.2 should not soon be considered and treated as the main development version, to become the main production version? B. All new features will go into 3.2. Only some will be backported to 2.x. So it seems that the flow should be to develop for 3.2 and maybe backport thereafter. 2.final Is there any thought of making 2.7 be 2.final? A. To my mind, the main reason to add features to 2.x is to make transition to 3.x easier, rather than to discourage transition to 3.x. B. Do we really want to encourage library developers to put their 'upgrade to a new version' energy into 2.x to 2.x+1 upgrades, rather than a 2.x to 3.y upgrades? C. Some people are sticking with some version of 2.x because they want a stable version with minimal disturbance. Such people might have preferred, for instance, getting 2.5.5 in April instead of the latest 2.6 release. Instead people 2.5 fixes are being told "Sorry. 2.5 is out of Maintenance phase and into SecurityFix only phase." Once 2.x is put in feature freeze, micro bugfix releases can appear for years, as long as bugs are found and patches submitted and committed. It should gradually become truly rock solid. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
