On 27/04/2010 11:38, Antoine Pitrou wrote:
Le mardi 27 avril 2010 à 03:23 -0700, Larry Hastings a écrit :
Pardon my general n00bishness, but I crave knowledge. IIUC currently if
you have a checkin in trunk that you *don't* want merged into py3k, you
must svnmerge block it in py3k. Otherwise it will be automatically
merged at some point.
Your U is not C. Nobody/nothing automerges. On the contrary, it is
highly recommended that you "svnmerge merge" changes yourself if you
want them to be merged (that is, ported).
It is also recommended that you "svnmerge block" changes which you think
shouldn't be ported to py3k. That way, it will leave the merge queue
clean and short (if it has ever been :-)).
Standard library changes are still *largely*
amenable to merging.
My guess is that *after* the release of 2.7, and probably also
after we switch to mercurial, py3k will become the equivalent of trunk.
Of course once we switch to mercurial the use of svnmerge will stop.
Bugfixes may still need merging from py3k to 2.7 (and 3.1), but not new
features. Allegedly merging between branches will be easier with
All the best,
python-committers mailing list
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.