Re: [python-committers] Is 3.1 open?
Le dimanche 14 mars 2010 à 03:52 +0100, Jesus Cea a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/14/2010 03:35 AM, Benjamin Peterson wrote: > >> Mercurial, where are you?. This would be a non issue :) > > > > How so? > > The release manager could clone the repository to getting it ready for > release, while the main repository accepts new changesets. The point > would be not stopping commits, ever. We could already do so with SVN, simply by opening a release branch when entering rc phase, and only merging selected (release blocking) fixes to that branch. There's nothing DVCS-specific here. > If the release manager needs some patches for the main repository, > he/she can cherrypick them manually or using a tool like > http://mercurial.selenic.com/wiki/TransplantExtension . Same with svnmerge. Regards Antoine. ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Is 3.1 open?
Antoine Pitrou wrote: > Le dimanche 14 mars 2010 à 03:52 +0100, Jesus Cea a écrit : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 03/14/2010 03:35 AM, Benjamin Peterson wrote: Mercurial, where are you?. This would be a non issue :) >>> How so? >> The release manager could clone the repository to getting it ready for >> release, while the main repository accepts new changesets. The point >> would be not stopping commits, ever. > > We could already do so with SVN, simply by opening a release branch when > entering rc phase, and only merging selected (release blocking) fixes to > that branch. There's nothing DVCS-specific here. I came across an interesting explanation from Joel Spolsky the other day as to why this isn't actually true (even with svnmerge): http://hginit.com/00.html Short version: SVN and other non-DVCS systems don't store enough (or the right) metadata to support merging properly, so branching becomes unnecessarily painful. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Is 3.1 open?
2010/3/17 Nick Coghlan : > Short version: SVN and other non-DVCS systems don't store enough (or the > right) metadata to support merging properly, so branching becomes > unnecessarily painful. This isn't really true these days given svn merge --reintegrate. -- Regards, Benjamin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Is 3.1 open?
Le jeudi 18 mars 2010 à 07:26 +1000, Nick Coghlan a écrit : > > > > We could already do so with SVN, simply by opening a release branch when > > entering rc phase, and only merging selected (release blocking) fixes to > > that branch. There's nothing DVCS-specific here. > > I came across an interesting explanation from Joel Spolsky the other day > as to why this isn't actually true (even with svnmerge): > http://hginit.com/00.html Sure, but Joel Spolsky's hand-waving notwithstanding, svnmerge generally works for the kind of use we are talking about (short-lived release branches with small cherry-picked transplants). Now for long-lived branches svnmerge is weaker, although not totally useless either; otherwise we wouldn't use it for py3k. ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Is 3.1 open?
Benjamin Peterson wrote: > 2010/3/17 Nick Coghlan : >> Short version: SVN and other non-DVCS systems don't store enough (or the >> right) metadata to support merging properly, so branching becomes >> unnecessarily painful. > > This isn't really true these days given svn merge --reintegrate. File renaming/moving still doesn't work properly though: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html There are limits to what you can do without tracking the original changesets. A DVCS does that, but SVN works by calculating diffs between different revisions without really caring about how those revisions came about. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Is 3.1 open?
Nick Coghlan wrote: > Benjamin Peterson wrote: >> 2010/3/17 Nick Coghlan : >>> Short version: SVN and other non-DVCS systems don't store enough (or the >>> right) metadata to support merging properly, so branching becomes >>> unnecessarily painful. >> This isn't really true these days given svn merge --reintegrate. > > File renaming/moving still doesn't work properly though: > http://blogs.open.collab.net/svn/2008/07/subversion-merg.html > > There are limits to what you can do without tracking the original > changesets. A DVCS does that, but SVN works by calculating diffs between > different revisions without really caring about how those revisions came > about. While that may be true in general, it is irrelevant in the context where you brought it up - whether or not we could do release branches with subversion. My expectation is that the release process won't change in this respect after the switch to Mercurial. We will continue to freeze the maintenance branch for releases, because everything else is too tedious for the release manager. E.g. let's assume the proposal would be to create a clone of the repository for the release branch: the time it takes to create a clone is too large to make it acceptable for the release manager to wait for that to complete. Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Is 3.1 open?
Le mercredi 17 mars 2010 à 23:02 +0100, "Martin v. Löwis" a écrit : > My expectation is that the release process won't change in this respect > after the switch to Mercurial. We will continue to freeze the > maintenance branch for releases, because everything else is too tedious > for the release manager. > > E.g. let's assume the proposal would be to create a clone of the > repository for the release branch: the time it takes to create a clone > is too large to make it acceptable for the release manager to wait for > that to complete. Too large? It should take a couple of minutes at most. By the way, the "official" mirror doesn't seem to work here: hg clone -v http://hg.python.org/cpython/ destination directory: cpython requesting all changes abandon : HTTP Error 414: Request-URI Too Large ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
