[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