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 Mercurial anyway...
All the best,
python-committers mailing list email@example.com http://mail.python.org/mailman/listinfo/python-committers