iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix some wording, rewrite section on branching strategies.

This commit is contained in:
Dirkjan Ochtman 2009-06-04 15:12:13 +00:00
parent 543ecd7f24
commit a19cdc384f
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
pep-0385.txt
View File

@ -20,7 +20,7 @@ still has to be performed. In the case of an important piece of
infrastructure like the version control system for a large, distributed infrastructure like the version control system for a large, distributed
project like Python, this is a significant effort. This PEP is an attempt 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 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 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 conversion, such that (a) as much of the svn metadata as possible is
@ -53,13 +53,17 @@ client. The latter makes it a little easier to switch between branches, but
often has somewhat unintuitive results for people (though this has been often has somewhat unintuitive results for people (though this has been
getting better in recent versions of Mercurial). getting better in recent versions of Mercurial).
For Python, I think it would work well to have cloned branches and keep most I'm still a bit on the fence about whether Python should adopt cloned
things separate. This is predicated on the assumption that most people work on branches and named branches. Since it usually makes more sense to tag releases
just one (or maybe two) branches at a time. Branches can be exposed separately, on the maintenance branch, for example, mainline history would not contain
though I would advocate merging old (and tagged!) branches into mainline so release tags if we used cloned branches. Also, Mercurial 1.2 and 1.3 have the
that people can easily revert to older releases. At what age of a release this necessary tools to make named branches less painful (because they can be
should be done can be debated (a natural point might be when the branch gets properly closed and closed heads are no longer considered in relevant cases).
unsupported, e.g. 2.4 at the release of 2.6).
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 Converting branches
------------------- -------------------
@ -133,7 +137,8 @@ hg-ssh
Developers should access the repositories through ssh, similar to the current 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. 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 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 Hooks
----- -----