[Python-checkins] r73220 - peps/trunk/pep-0385.txt

[dirkjan.ochtman]

Author: dirkjan.ochtman
Date: Thu Jun  4 17:12:13 2009
New Revision: 73220

Log:
Fix some wording, rewrite section on branching strategies.

Modified:
   peps/trunk/pep-0385.txt

Modified: peps/trunk/pep-0385.txt
==============================================================================
--- peps/trunk/pep-0385.txt	(original)
+++ peps/trunk/pep-0385.txt	Thu Jun  4 17:12:13 2009
@@ -20,7 +20,7 @@
 infrastructure like the version control system for a large, distributed
 project like Python, this is a significant effort. This PEP is an attempt
 to describe the steps that must be taken for further discussion. It's
-equivalent to `PEP 347`_, which discussed the migration to SVN.
+somewhat similar to `PEP 347`_, which discussed the migration to SVN.
 
 To make the most of hg, I (Dirkjan) would like to make a high-fidelity
 conversion, such that (a) as much of the svn metadata as possible is
@@ -53,13 +53,17 @@
 often has somewhat unintuitive results for people (though this has been
 getting better in recent versions of Mercurial).
 
-For Python, I think it would work well to have cloned branches and keep most
-things separate. This is predicated on the assumption that most people work on
-just one (or maybe two) branches at a time. Branches can be exposed separately,
-though I would advocate merging old (and tagged!) branches into mainline so
-that people can easily revert to older releases. At what age of a release this
-should be done can be debated (a natural point might be when the branch gets
-unsupported, e.g. 2.4 at the release of 2.6).
+I'm still a bit on the fence about whether Python should adopt cloned
+branches and named branches. Since it usually makes more sense to tag releases
+on the maintenance branch, for example, mainline history would not contain
+release tags if we used cloned branches. Also, Mercurial 1.2 and 1.3 have the
+necessary tools to make named branches less painful (because they can be
+properly closed and closed heads are no longer considered in relevant cases).
+
+A disadvantage might be that the used clones will be a good bit larger (since
+they essentially contain all other branches as well). Perhaps it would be a 
+good idea to distinguish between feature branches (which would be done trough
+a separate clone) and release branches (which would be named).
 
 Converting branches
 -------------------
@@ -133,7 +137,8 @@
 Developers should access the repositories through ssh, similar to the current
 setup. Public keys can be used to grant people access to a shared hg@ account.
 A hgwebdir instance should also be set up for easy browsing and read-only
-access. Some facility for sandboxes/incubator repositories could be discussed.
+access. If we're using ssh, developers should trivially be able to start new
+clones (for longer-term features that profit from a separate branch).
 
 Hooks
 -----