Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Sorry Dirkjan - I just noticed I didn't CC you on this mail originally. I'm wondering if you have any more thoughts on these EOL issues and if there is anything I can do to help? Cheers, Mark On 4/07/2009 2:03 PM, Mark Hammond wrote: On 4/07/2009 12:30 PM, Nick Coghlan wrote: ... I think t

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009/7/4 Brett Cannon : >> > While I really like the idea of using named branches for each release so >> > that there is a single py3k branch that contains all relevant history >> > for >> > every release, I think we should start simple and go with cloned >> > branches. >> > That way the workflow d

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

R. David Murray writes: > On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote: > > I've seen a few discussions about this, but no final statement > > of what strategy to follow and whether hg makes this easier (AFAIR, > > that was the main argument for switching to hg). Yes, yes, yes, and no. I

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis wrote: > I think you are proposing that there is no prefix because the chance > for a misidentification of some word as a hg revision number is small, > as it has to be exactly 12 hex digits. So triggering it accidentally would require a 12 letter word or object name that used only

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

>> I've seen a few discussions about this, but no final statement >> of what strategy to follow and whether hg makes this easier (AFAIR, >> that was the main argument for switching to hg). > > I think the main reason for switching was that it would make it easier > for non-core-committers to maint

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

>> Hmm, no prefix or suffix ? > > No, not really. hg often shows revision integers as well, but as they > aren't globally consistent, they're of little value in communicating > changeset pointers. I think MAL wasn't asking for a "1354:" prefix, but for a, say, "r" or "R" prefix, or perhaps "V" or

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

M.-A. Lemburg wrote: > Dirkjan Ochtman wrote: >> On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote: >>> Is there a standard notation for hg revisions that roundup could >>> detect and turn into links (much like it does for svn) ? >> [a-f0-9]{12} should mostly do. > > Hmm, no prefix or suffix ? >

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote: The merge process itself is more or less clear. What I'm missing is the agreed upon strategy for applying the patches to the various branches. I've seen a few discussions about this, but no final statement of what strategy to follow and whether h

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Tue, Jul 7, 2009 at 15:32, M.-A. Lemburg wrote: > Hmm, no prefix or suffix ? No, not really. hg often shows revision integers as well, but as they aren't globally consistent, they're of little value in communicating changeset pointers. > So we'll always have to write "see deadbeefdeadbeefff fo

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman wrote: > On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote: >> Is there a standard notation for hg revisions that roundup could >> detect and turn into links (much like it does for svn) ? > > [a-f0-9]{12} should mostly do. Hmm, no prefix or suffix ? So we'll always have to write

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Brett Cannon wrote: > On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg wrote: > >> Dirkjan Ochtman wrote: >>> In response to some rumblings on python-committers and just to request >>> more feedback, a progress report. I know it's long, I've tried to put >>> to keep it concise and chunked, though. >>

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote: > Is there a standard notation for hg revisions that roundup could > detect and turn into links (much like it does for svn) ? [a-f0-9]{12} should mostly do. (Sorry for my absence from the discussion for some time. I'll try to update the PEP and s

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Nick Coghlan wrote: > Martin v. Löwis wrote: >>> I suggest that we also run a version of that redirection filter to remap >>> the old svn.python.org links in addition to making them accessible >>> through hg.python.org as Dirkjan proposed. >> Not sure what links you are talking about, but we also n

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis wrote: >> I suggest that we also run a version of that redirection filter to remap >> the old svn.python.org links in addition to making them accessible >> through hg.python.org as Dirkjan proposed. > > Not sure what links you are talking about, but we also need to keep the > curre

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> I suggest that we also run a version of that redirection filter to remap > the old svn.python.org links in addition to making them accessible > through hg.python.org as Dirkjan proposed. Not sure what links you are talking about, but we also need to keep the current svn.python.org up as-is, for

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

M.-A. Lemburg wrote: > Dirkjan Ochtman wrote: > * Our tracker, checkin messages, online documentation and lots of >Python resources on the web are full of references to the >Subversion rXYZ notation of changesets. > >The PEP has to provide some way to gracefully provide a redirect >

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg wrote: > Dirkjan Ochtman wrote: > > In response to some rumblings on python-committers and just to request > > more feedback, a progress report. I know it's long, I've tried to put > > to keep it concise and chunked, though. > > Two things: > > * We ne

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman wrote: > In response to some rumblings on python-committers and just to request > more feedback, a progress report. I know it's long, I've tried to put > to keep it concise and chunked, though. Two things: * We need some form of documentation of how committers are expected to

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis wrote: > What will need debate and discussion in the PEP is the workflow, ie. > the order in which changes should be applied to the branches. Particularly since there isn't even "one true workflow" *now*. I see three main variants go by on Python-checkins: - svnmerge based - com

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009/7/5 average : >>> Is it really that confusing? I have never heard of anyone asking "what >>> is py3k?" >> >> Do you read python-list? It has been asked. Also, some people seem to >> think that py3k is different from python 3. > > Personally, I vote for keeping the "3k" for 3000 (or is it 3072?

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

>> Is it really that confusing? I have never heard of anyone asking "what >> is py3k?" > > Do you read python-list? It has been asked. Also, some people seem to > think that py3k is different from python 3. Personally, I vote for keeping the "3k" for 3000 (or is it 3072?). I believe that py3k rep

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

>> In proposing such a workflow, consider these requirements: > > It seems that there is a consensus to separate the 2.x and 3.x repos, > and that also makes sense to me. (I think) I wasn't primarily talking about the representation of branches in hg - to that, I fully trust recommendations from

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Georg Brandl writes: > What I really want to see is the common-subset approach for > maintenance branches. IMO, this unfortunately unlikely to work as you seem to expect, for a two technical reasons and for a social reason. The first technical reason is that a maintenance branch really is a br

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis schrieb: >> It will handle it, for sure, but I think it would all go easier if we >> could work with stricter subset branches (and leave the effective >> cherrypicking for the occasional problem). > > So I think the PEP should propose a workflow (or: merge flow) if you > think we w

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis schrieb: >> We could add another value in the tuple that specifies the VCS: >> ('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that >> VCSs are not universally the same, but the concept of a revision is >> universal. > > Actually, I think that's not the case. For b

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, 4 Jul 2009 at 12:28, Brett Cannon wrote: On Sat, Jul 4, 2009 at 01:03, Dirkjan Ochtman wrote: On Fri, Jul 3, 2009 at 20:04, Brett Cannon wrote: Fine by me as long as people realize that if anything is questionable then the switch will not happen. Getting this right takes precedence

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, Jul 4, 2009 at 01:55, Terry Reedy wrote: > Brett Cannon wrote: > > I would very much like the 'k' dropped from the py3 name. It was a >>funny joke when py3 was vaporware, now it is excess baggage which >>only puzzles non-insiders and newcomers. >> >> >> Is it really that confu

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, Jul 4, 2009 at 01:03, Dirkjan Ochtman wrote: > On Fri, Jul 3, 2009 at 20:04, Brett Cannon wrote: > > Fine by me as long as people realize that if anything is questionable > then > > the switch will not happen. Getting this right takes precedence over any > > deadline. And obviously we wil

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman wrote: > On Sat, Jul 4, 2009 at 07:13, Nick Coghlan wrote: >> I'd guess that the only way to keep those functional is to keep >> svn.python.org around in read-only mode. > > No, actually: the idea (I think I floated it in the PEP, as well), is > that I can write a simple extension

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> I see that George Brandl and Martin van Loewis seem to be accomodating > your viewpoint, but I don't get the impression that either you (as the > hg migration proponent) nor they (as core committers) realize how far > apart your assumptions are. Actually, I (probably) don't agree to a merge flo

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Brett Cannon wrote: I would very much like the 'k' dropped from the py3 name. It was a funny joke when py3 was vaporware, now it is excess baggage which only puzzles non-insiders and newcomers. Is it really that confusing? I have never heard of anyone asking "what is py3k?" Do

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, Jul 4, 2009 at 00:37, Barry Warsaw wrote: > Doesn't Mercurial support an Subversion bridge?  Would it be possible to > provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6, and > 3.1?  If so, then the release managers would simply have to cut their > releases from the svn

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, Jul 4, 2009 at 00:09, "Martin v. Löwis" wrote: > I would drop the roundup integration from the things that need to > be done pre-migration - there currently is no svn integration, so > not having it for hg is not a step backwards. Yeah, I mean just the linking here. > In the first sentenc

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 17:17, Georg Brandl wrote: > Do you have a key to the second column in that file? E.g. the difference > between "strip" and "discard" is not clear to me. "strip partial"? strip == discard. strip = remove, merged should be obvious, keep-clone means we'll keep the branch, in a

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, Jul 4, 2009 at 07:13, Nick Coghlan wrote: > I'd guess that the only way to keep those functional is to keep > svn.python.org around in read-only mode. No, actually: the idea (I think I floated it in the PEP, as well), is that I can write a simple extension for hgweb that knows the mapping

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 20:04, Brett Cannon wrote: > Fine by me as long as people realize that if anything is questionable then > the switch will not happen. Getting this right takes precedence over any > deadline. And obviously we will need to do at least one live conversion on > python.org hardwar

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

P.J. Eby writes: > Wouldn't the simple thing to do in Mercurial, just be to use > different repositories for long-lived branches? I mean, if you're > not merging them that much anyway, what's the point? I basically agree with that, and so does Dirkjan, I think. I'm not sure why he brought

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis wrote: > Ah, right. That must be done, of course (although I suppose there is > little hope to have the existing references continue to work). I'd guess that the only way to keep those functional is to keep svn.python.org around in read-only mode. Although I'm not entirely sure ab

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

At 12:20 PM 7/4/2009 +0900, Stephen J. Turnbull wrote: IME, Mercurial strongly encourages a non-branching style. Although I can't fully explain in concrete terms what makes me feel that way, it's certainly consistent with your own inclination to advise "subset branches". Part of it comes from t

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Nick Coghlan writes: > I'm not clear on the rationale for the explicit CRLF line ending on the > email test message, but I would guess it is to ensure that the email > module can handle CRLF line endings correctly regardless of platform. IIRC, that's just the standard for text email. Lines mu

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 4/07/2009 12:30 PM, Nick Coghlan wrote: ... I think there needs to be a solid answer in place for these use cases before the actual migration to Mercurial takes place. A hand-waving "use win32text" isn't enough - it needs to be "use win32text with these exact settings" (with server side hook s

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, 4 Jul 2009 04:22:57 am Terry Reedy wrote: > I would very much like the 'k' dropped from the py3 name. It was a > funny joke when py3 was vaporware, now it is excess baggage which > only puzzles non-insiders and newcomers. +1 Some day we'll be using Python3.7 and wondering what the "k" me

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Nick Coghlan wrote: > Martin v. Löwis wrote: >> I would drop the roundup integration from the things that need to >> be done pre-migration - there currently is no svn integration, so >> not having it for hg is not a step backwards. > > That's not quite true - the tracker turns text like "r64537" i

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman writes: > On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull wrote: > > I'll have to try them again now that 1.3 is out, but I found Mercurial > > named branches fundamentally unsuited to release management. > > Can you explain why, please? It's not clear from what you say > b

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Mark Hammond wrote: > This *appears* to be correct at first glance, but in practice it doesn't > interact well with wildcards specifications - particularly > '**=cleverencode'. I started a thread on the ML and submitted a patch a > few months ago to fix this and it was accepted, but sadly it seeme

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis wrote: > I would drop the roundup integration from the things that need to > be done pre-migration - there currently is no svn integration, so > not having it for hg is not a step backwards. That's not quite true - the tracker turns text like "r64537" into a link to the appropriate

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 4/07/2009 11:20 AM, Nick Coghlan wrote: I didn't realise Mercurial didn't have a way for a repository to provide versioned extension settings, but in this case I think using our own server side hook can deal with the problem (either adding it to the existing whitespace hook that checks for ta

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Brett Cannon wrote: > On Fri, Jul 3, 2009 at 15:00, Dirkjan Ochtman > wrote: > Actually, I currently have /cpython to also make CPython less special > among it's peers, but that idea was met with some resistance on > #python-dev. > > Don't worry about doing

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote: As long as the difference between \r\n- and \n-based files is clear and can be reasoned about, I don't see why having some of both (I'm assuming an overwhelming majority will have one, and only a few the other) is a big problem. But feel free to enli

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Mark Hammond wrote: > On 4/07/2009 12:04 AM, Nick Coghlan wrote: > The big problem I have with win32text is that the rules are not > versioned, meaning we will rely on every (windows only?) developer > manually enabling the win32text extension, then manually adding these > rules to an unversioned h

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> Doesn't Mercurial support an Subversion bridge? Would it be possible to > provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6, > and 3.1? If so, then the release managers would simply have to cut > their releases from the svn copy instead of the hg master. /All/ other > wor

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote: On Fri, Jul 3, 2009 at 15:31, Mark Hammond wrote: So we must work without effective EOL support? I fear we will end up like the mozilla hg repo with some files in windows line endings and some with linux. While my editing tools are good enough to

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 4/07/2009 12:04 AM, Nick Coghlan wrote: However, I expect that would still be painful to work with for Windows developers, even if it prevented any line ending problems from making their way into the main repository. I believe that is where the win32text extensions can help. Looking at the Wi

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Jul 3, 2009, at 6:15 PM, Martin v. Löwis wrote: I'm fine with that plan - but the original problem remains. We will surely release 2.6.4 at some point, and it will have a different version identification (based on hg rev ids). So those existing applications (which are probably few) will t

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Barry Warsaw wrote: > On Jul 3, 2009, at 5:00 PM, Martin v. Löwis wrote: > >> I'm -1 on calling it "sys.revision", as this makes it difficult to >> tell what the actual versioning system was, and hence how the >> data should be interpreted. It will already be a problem for 2.6, >> when 2.6.3 will

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> - First of all, I've got the basic conversion down, I've done it a few > times now, with progressively better results. You can view some > results at http://hg.python.org/, which has a preliminary cpython > repository. *** The changeset hashes for that repo will change, so you > won't be able to

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Jul 3, 2009, at 5:00 PM, Martin v. Löwis wrote: I'm -1 on calling it "sys.revision", as this makes it difficult to tell what the actual versioning system was, and hence how the data should be interpreted. It will already be a problem for 2.6, when 2.6.3 will currently have a sys.subversion[2]

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 15:00, Dirkjan Ochtman wrote: > On Fri, Jul 3, 2009 at 23:41, Brett Cannon wrote: > > If we make it universal I say it should be '2.x' and '3.x'. The whole > 'py' > > prefix is redundant. > > Right, I was aiming for /python/2.x and /python/3.x as well. > > Actually, I curre

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 23:41, Brett Cannon wrote: > If we make it universal I say it should be '2.x' and '3.x'. The whole 'py' > prefix is redundant. Right, I was aiming for /python/2.x and /python/3.x as well. Actually, I currently have /cpython to also make CPython less special among it's peers

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> So are you saying we should drop the idea of a revision value > altogether, or just embrace the differences and add a sys.mercurial > attribute? That's what I would propose. It should be a best-effort(*) approach at providing all information that is needed to really find the source used for the

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 14:52, "Martin v. Löwis" wrote: > > We could add another value in the tuple that specifies the VCS: > > ('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that > > VCSs are not universally the same, but the concept of a revision is > > universal. > > Actually,

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> We could add another value in the tuple that specifies the VCS: > ('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that > VCSs are not universally the same, but the concept of a revision is > universal. Actually, I think that's not the case. For bzr, the usual way of identifying

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 11:22, Terry Reedy wrote: > Dirkjan Ochtman wrote: > > It needs to be decided where the hg repositories will live. I'd like >> to propose to keep the hgwebdir instance at hg.python.org. This is an >> accepted standard for many organizations, and an easy parallel to >> svn.

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 14:00, "Martin v. Löwis" wrote: > > Should we consider adding a sys.revision attribute and begin the > > deprecation of sys.subversion? > > I wouldn't mind killing sys.subversion "right away" (i.e. in trunk > and 3k - obviously it has to stay in 2.6 and 3.1, and all the old

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> Should we consider adding a sys.revision attribute and begin the > deprecation of sys.subversion? I wouldn't mind killing sys.subversion "right away" (i.e. in trunk and 3k - obviously it has to stay in 2.6 and 3.1, and all the older branches). I'm -1 on calling it "sys.revision", as this makes

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> It will handle it, for sure, but I think it would all go easier if we > could work with stricter subset branches (and leave the effective > cherrypicking for the occasional problem). So I think the PEP should propose a workflow (or: merge flow) if you think we would be better off with a differen

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

MRAB wrote: Terry Reedy wrote: Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (trunk) rep

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

>> This is exactly why I was asking for your advice - I can't work out how to >> work effectively with win32text as it stands myself, so remain stuck >> accidently checking in files with inappropriate line endings and stuck >> working out how to move pywin32's CVS repo with abandoning the very >> p

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> So we must work without effective EOL support? If that's the case (i.e. no effective EOL support, the way svn supported it), then I think the PEP should make that clear (e.g. in a discussion section). For the server-side hooks: it would be good to know exactly what they check, wrt. line endings

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 03, 2009, Brett Cannon wrote: > > Should we consider adding a sys.revision attribute and begin the deprecation > of sys.subversion? +1 -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "as long as we like the same operating system, things are cool." --p

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Terry Reedy wrote: Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (trunk) repo might live

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (trunk) repo might live at http://hg.python.

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Thu, Jul 2, 2009 at 13:42, Dirkjan Ochtman wrote: > In response to some rumblings on python-committers and just to request > more feedback, a progress report. I know it's long, I've tried to put > to keep it concise and chunked, though. > > - First of all, I've got the basic conversion down, I

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman schrieb: > - Fifth, here's a list of things, off the top of my head, that still need > doing: > > * Get agreement on branch strategy and branch processing (list of > branches + proposed handling at > http://hg.python.org/pymigr/file/tip/all-branches.txt) <--- PLEASE > REVIEW Do

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Mark Hammond wrote: > So we must work without effective EOL support? I fear we will end up > like the mozilla hg repo with some files in windows line endings and > some with linux. While my editing tools are good enough to preserve > existing EOL styles, I've found myself accidentally checking in

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull wrote: > I'll have to try them again now that 1.3 is out, but I found Mercurial > named branches fundamentally unsuited to release management. Can you explain why, please? It's not clear from what you say below. > Ditto named branches.  The proble

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 15:31, Mark Hammond wrote: > So we must work without effective EOL support?  I fear we will end up like > the mozilla hg repo with some files in windows line endings and some with > linux.  While my editing tools are good enough to preserve existing EOL > styles, I've found m

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 3/07/2009 9:28 PM, Dirkjan Ochtman wrote: On Fri, Jul 3, 2009 at 01:01, Mark Hammond wrote: Although this has come up in the past, I don't recall a resolution. What is your plan to handle svn:eol-style? We have some files in the tree which need that support and it isn't clear to me how

[Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman writes: > Mercurial has two basic ways of using branches: cloned branches, where > each branch is kept in a separate repository, and named branches, > where each revision keeps metadata to note on which branch it belongs. > The former makes it easier to distinguish branches, at

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 01:01, Mark Hammond wrote: > Although this has come up in the past, I don't recall a resolution. > > What is your plan to handle svn:eol-style?  We have some files in the tree > which need that support and it isn't clear to me how that would work with > the existing win32text

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 3/07/2009 6:42 AM, Dirkjan Ochtman wrote: In response to some rumblings on python-committers and just to request more feedback, a progress report. I know it's long, I've tried to put to keep it concise and chunked, though. Although this has come up in the past, I don't recall a resolution.

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

2009/7/2 Dirkjan Ochtman : > In response to some rumblings on python-committers and just to request > more feedback, a progress report. I know it's long, I've tried to put > to keep it concise and chunked, though. Thanks very much for working on this, Dirkjan. It may seem rather thankless now, but

[Python-Dev] Mercurial migration: progress report (PEP 385)

In response to some rumblings on python-committers and just to request more feedback, a progress report. I know it's long, I've tried to put to keep it concise and chunked, though. - First of all, I've got the basic conversion down, I've done it a few times now, with progressively better results.