[Python-checkins] r68917 - peps/trunk/pep-0374.txt
brett.cannon
python-checkins at python.org
Sun Jan 25 04:55:05 CET 2009
Author: brett.cannon
Date: Sun Jan 25 04:55:05 2009
New Revision: 68917
Log:
Mention another style of dealing with patches for svn by heavy use of ``svn
revert -R``.
Also make it more clear how in svn we don't follow a port-forward strategy but
instead a tree-like one.
Modified:
peps/trunk/pep-0374.txt
Modified: peps/trunk/pep-0374.txt
==============================================================================
--- peps/trunk/pep-0374.txt (original)
+++ peps/trunk/pep-0374.txt Sun Jan 25 04:55:05 2009
@@ -610,6 +610,10 @@
svn commit -m "Some patch."
cd ..
rm -r issue0000
+
+Another option is to only have a single checkout running at any one
+time and use ``svn diff`` along with ``svn revert -R`` to store away
+independent changes you may have made.
bzr
@@ -679,37 +683,41 @@
Backport
--------
-As a core developer, I want to apply a patch to 2.6, 2.7 and 3.0, so
-that I can fix a problem in all three versions.
-
-Python always has at least the trunk and the last major release to
-potentially backport patches to. Currently, though, the situation is
-even more complicated than that as we also have to port forward
-changes as well. This scenario assumes one needs to apply a patch to
-2.6, 2.7, and 3.0, but not necessarily in that order (which is why
-there is no list of required steps for this scenario). It is assumed
-a developer has a checkout/clone of all three versions. There is also
-a revision that needs to be prevented from ever being merged into
-another branch.
+As a core developer, I want to apply a patch to 2.6, 2.7, 3.0, and 3.1
+so that I can fix a problem in all three versions.
+Thanks to always having the cutting-edge and the latest release
+version under development, Python currently has four branches being
+worked on simultaneously. That makes it important for a change to
+propagate easily through various branches.
svn
'''
+
+Because of Python's use of svnmerge, changes start with the trunk
+(2.7) and then get merged to the release version of 2.6. To get the
+change into the 3.x series, the change is merged into 3.1, fixed up,
+and then merged into 3.0 (2.7 -> 2.6; 2.7 -> 3.1 -> 3.0).
+
+This is in contrast to a port-forward strategy where the patch would
+have been added to 2.6 and then pulled forward into newer versions
+(2.6 -> 2.7 -> 3.0 -> 3.1).
+
::
# Assume patch applied to 2.7 in revision 0000.
cd release26-maint
svnmerge merge -r 0000
# Resolve merge conflicts and make sure patch works.
- svn commit -F svnmerge-commit-message.txt
+ svn commit -F svnmerge-commit-message.txt # revision 0001.
cd ../py3k
svnmerge merge -r 0000
# Same as for 2.6, except Misc/NEWS changes are reverted.
svn revert Misc/NEWS
- svn commit -F svnmerge-commit-message.txt
- # Block revision 0001 from being merged from 2.7 into 3.0.
- svnmerge block -r 0001
- svn ci -F svnmerge-commit-message.txt
+ svn commit -F svnmerge-commit-message.txt # revision 0002.
+ cd ../release30-maint
+ svnmerge merge -r 0002
+ svn commit -F svnmerge-commit-message.txt # revision 0003.
bzr
More information about the Python-checkins
mailing list