<br><br><div class="gmail_quote">On Mon, Aug 3, 2009 at 04:53, Dirkjan Ochtman <span dir="ltr"><<a href="mailto:dirkjan@ochtman.nl">dirkjan@ochtman.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The diff below should reflect changes from the discussion we had last<br>
time. Please review. (Some comments may be more appropriate for the<br>
other threads I just kicked off.)<br>
<br>
Cheers,<br>
<br>
Dirkjan<br>
<br>
Index: pep-0385.txt<br>
===================================================================<br>
--- pep-0385.txt (revision 74294)<br>
+++ pep-0385.txt (revision 74296)<br>
@@ -59,27 +59,25 @@<br>
often has somewhat unintuitive results for people (though this has been<br>
getting better in recent versions of Mercurial).<br>
<br>
-I'm still a bit on the fence about whether Python should adopt cloned<br>
-branches and named branches. Since it usually makes more sense to tag releases<br>
-on the maintenance branch, for example, mainline history would not contain<br>
-release tags if we used cloned branches. Also, Mercurial 1.2 and 1.3 have the<br>
-necessary tools to make named branches less painful (because they can be<br>
-properly closed and closed heads are no longer considered in relevant cases).<br>
+The current proposal is to use named branches for release branches and adopt<br>
+cloned branches for feature branches, with one exception to this rule: the 3.x<br>
+branches will be kept in separate clones from the 2.x branches. I think this<br>
+provides an optimal hybrid approach for Python's uses of branching.<br>
</blockquote><div><br></div><div>Sounds good to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
-A disadvantage might be that the used clones will be a good bit larger (since<br>
-they essentially contain all other branches as well). This can me mitigated by<br>
-keeping non-release (feature) branches in separate clones. Also note that it's<br>
-still possible to clone a single named branch from a combined clone, by<br>
-specifying the branch as in hg clone <a href="http://hg.python.org/main/#2.6-maint.
-Keeping" target="_blank">http://hg.python.org/main/#2.6-maint.<br>
-Keeping</a> the py3k history in a separate clone problably also makes sense.<br>
+Differences between named branches and cloned branches:<br>
<br>
-XXX To do: size comparison for selected separation scenarios.<br>
+* Tags in a different (maintenance) clone aren't available in the local clone<br>
+* Clones with named branches will be larger, since they contain more data<br>
<br>
+(The Mercurial book discourages the use of named branches, but it is, in this<br>
+respect, somewhat outdated. Named branches have gotten much easier to use<br>
+since that comment was written, due to improvements in hg.)<br>
+<br>
Converting branches<br>
-------------------<br>
<br>
There are quite a lot of branches in SVN's branches directory. I propose to<br>
-clean this up a bit, by employing the following the strategy:<br>
+clean this up a bit, by following this basic strategy:<br>
<br>
* Keep all release (maintenance) branches<br>
* Discard branches that haven't been touched in 18 months, unless somone<br>
@@ -87,6 +85,21 @@<br>
* Keep branches that have been touched in the last 18 months, unless someone<br>
indicates the branch can be deprecated<br>
<br>
+There's a `branch map`_ available that shows info about each branch:<br>
+<br>
+* keep-clone means we'll keep that branch in a separate clone<br>
+* keep-named means we'll keep that branch as a named branch in one of<br>
the clones<br>
+* strip means we won't keep that branch<br>
+* streamed-merge means that it got merged by committing several new revisions<br>
+ to the other branch<br>
+* merged-r* means the branch got merged in the named revision<br>
+* merges? means I haven't checked/found out yet whether that branch was ever<br>
+ merged<br>
+* ? means that your input would be even more helpful than for the other items<br>
+* some items have no action yet, feel free to treat that as just '?'<br>
+<br>
+.. _branch map: <a href="http://hg.python.org/pymigr/file/tip/all-branches.txt" target="_blank">http://hg.python.org/pymigr/file/tip/all-branches.txt</a><br>
+<br>
Converting tags<br>
---------------<br>
<br>
@@ -95,8 +108,8 @@<br>
we should keep all release tags, and consider other tags for inclusion based<br>
on requests from the developer community. I'd like to consider unifying the<br>
release tag naming scheme to make some things more consistent, if people feel<br>
-that won't create too many problems. For example, Mercurial itself just uses<br>
-'1.2.1' as a tag, where CPython would currently use r121.<br>
+that won't create too many problems. The current proposal is to bring old<br>
+release tags in line with the current practice of release tag naming.<br>
<br>
Author map<br>
----------<br>
@@ -119,17 +132,19 @@<br>
possible forms of pattern matching. The current Python repository already<br>
includes a rudimentary .hgignore file to help with using the hg mirrors.<br>
<br>
-It might be useful to have the .hgignore be generated automatically from<br>
-svn:ignore properties. This would make sure all historic revisions also have<br>
-useful ignore information (though one could argue ignoring isn't really<br>
-relevant to just checking out an old revision).<br>
+Since the current Python repository already includes a .hgignore file (for use<br>
+with hg mirrors), we'll just use that. Generating full history of the file<br>
+was debated but deemed impractical (because it's relatively hard with fairly<br>
+little gain, since ignoring is less important for older revisions).<br>
<br>
Revlog reordering<br>
-----------------<br>
<br>
-As an optional optimization technique, we should consider trying a reordering<br>
-pass on the revlogs (internal Mercurial files) resulting from the conversion.<br>
-In some cases this results in dramatic decreases in on-disk repository size.<br>
+As an optional optimization technique, I have performed a reordering pass on<br>
+the revlogs (internal Mercurial files) resulting from the conversion. In some<br>
+cases this results in dramatic decreases in on-disk repository size. This<br>
+especially makes sense for the manifest (where it really helps out quite a lot)<br>
+and oft-edited files like NEWS.txt (with an admittedly smaller effect).<br>
<br>
Other repositories<br>
------------------<br>
@@ -138,7 +153,14 @@<br>
converted. What other projects in the <a href="http://svn.python.org" target="_blank">svn.python.org</a> repository should be<br>
converted? Do we want to convert the peps repository? distutils? others?<br>
<br>
+There's now an initial stab at converting the Jython repository. The current<br>
+tip of hgsubversion unfortunately fails at some point. Pending investigation.<br>
<br>
+Other repositories that would like to converted to Mercurial can announce<br>
+themselves to me after the main Python migration is done, and I'll take care<br>
+of their needs.<br>
+<br>
+<br>
Infrastructure<br>
==============<br>
<br>
@@ -165,18 +187,34 @@<br>
lines. Open issue: do we check only the tip after each push, or do we check<br>
every commit in a changegroup?<br>
<br>
-* commit mails: we can leverage the notify extension for this<br>
+* commit mails: we can leverage the notify extension for this. Emails will<br>
+ include diffs for each changeset committed against the repository.<br>
<br>
* buildbots: both the regular and the community build masters must be notified.<br>
Fortunately buildbot includes support for hg. I've also implemented this for<br>
Mercurial itself, so I don't expect problems here.<br>
<br>
* check contributors: in the current setup, all changesets bear the username of<br>
- committers, who must have signed the contributor agreement. In a DVCS, the<br>
- committers are not necessarily the same people who push, and so we can't<br>
- check if the committer is a contributor. We could use a hook to check if the<br>
- committer is a contributor if we keep a list of registered contributors.<br>
+ committers, who must have signed the contributor agreement. We might want to<br>
+ use a hook to check if the committer is a contributor if we keep a list of<br>
+ registered contributors. Then, the hook might warn users that push a group<br>
+ of revisions containing changesets from unknown contributors.<br>
</blockquote><div><br></div><div>Is this from people who submit patch sets to <a href="http://bugs.python.org">bugs.python.org</a> that include the individual commits? Or is this for core developers?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
+End-of-line conversions<br>
+-----------------------<br>
+<br>
+There has been some discussion about the lack of end-of-line conversion support<br>
+in Mercurial. While Mercurial comes with a win32text extension that provides<br>
+some basic support for converting end-of-line data on a file-name pattern<br>
+basis, the lack of exclusion (for specifying broad rules with exceptions) and<br>
+the use of hgrc files (which can't be versioned) make it less than ideal.<br>
+<br>
+I think the primary line of defense for prevention of inappropriate newlines<br>
+should be hooks on the server side which basically turn down any changegroup<br>
+or changeset introducing such data. The use of the win32text extension (which<br>
+can hopefully be improved/extended to support the usage scenarios mentioned<br>
+above) and/or a commit-time hook could be the first line of defense.<br>
+<br>
hgwebdir<br>
--------<br>
<br>
@@ -185,7 +223,16 @@<br>
build a quick extension to augment the URL rev parser so that it can also take<br>
r[0-9]+ args and come up with the matching hg revision.<br>
<br>
+roundup<br>
+-------<br>
<br>
+We'll come up with an auto-linking plugin for roundup, which can match a<br>
+changeset identifier (possibly with a branch prefix), and link it to the<br>
+appropriate revision in the hgwebdir instance. Second, the script above (in<br>
+the hgwebdir section) will make sure that old links to revision should continue<br>
+to work (by pointing to the hg changeset that reflects the svn revision).<br>
+<br>
+<br>
After migration<br>
===============<br>
<br>
@@ -222,37 +269,32 @@<br>
.. _wiki: <a href="http://www.selenic.com/mercurial/wiki/" target="_blank">http://www.selenic.com/mercurial/wiki/</a><br>
.. _parts of the developer FAQ: <a href="http://www.python.org/dev/faq/#version-control" target="_blank">http://www.python.org/dev/faq/#version-control</a><br>
<br>
-Think first, commit later?<br>
---------------------------<br>
+Proposed workflow<br>
+-----------------<br>
<br>
-In recent history, old versions of Python have been maintained by a select<br>
-group of people backporting patches from trunk to release branches. While<br>
-this may not scale so well as the development pace grows, it also runs into<br>
-some problems with the current crop of distributed versioning tools. These<br>
-tools (I believe similar problems would exist for either git, bzr, or hg,<br>
-though some may cope better than others) are based on the idea of a Directed<br>
-Acyclic Graph (or DAG), meaning they keep track of relations of changesets.<br>
+I propose two workflows for the migration of patches between several branches.<br>
<br>
-Mercurial itself has a stable branch which is a ''strict'' subset of the<br>
-unstable branch. This means that generally all fixes for the stable branch<br>
-get committed against the tip of the stable branch, then they get merged into<br>
-the unstable branch (which already contains the parent of the new cset). This<br>
-provides a largely frictionless environment for moving changes from stable to<br>
-unstable branches. Mistakes, where a change that should go on stable goes on<br>
-unstable first, do happen, but they're usually easy to fix. That can be done by<br>
-copying the change over to the stable branch, then trivial-merging with<br>
-unstable -- meaning the merge in fact ignores the parent from the stable<br>
-branch).<br>
+For migration within 2.x or 3.x branches, I propose a patch always gets<br>
+committed to the oldest branch where it applies first. Then, the resulting<br>
+changeset can be merged using hg merge to all newer branches within that<br>
+series (2.x or 3.x). If it does not apply as-is to the newer branch, hg revert<br>
+can be used to easily revert to the new-branch-native head, patch in some<br>
+alternative version of the patch (or none, if it's not applicable), then commit<br>
+the merge. The premise here is that all changesets from an older branch within<br>
+the series are eventually merged to all newer branches within the series.<br>
<br>
-This strategy means a little more work for regular committers, because they<br>
-have to think about whether their change should go on stable or unstable; they<br>
-may even have to ask someone else (the RM) before committing. But it also<br>
-relieves a dedicated group of committers of regular backporting duty, in<br>
-addition to making it easier to work with the tool.<br>
+The upshot is that this provides for the most painless merging procedure. The<br>
+downside is that in the general case, people have to think about the oldest<br>
+branch to which the patch should be applied before actually applying it.<br>
</blockquote><div><br></div><div>People should be doing that anyway intra-major version, so it should be a very minor pain point. Plus named branches make this straightforward, right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
-Now would be a good time to consider changing strategies in this regard,<br>
-although it would be relatively easy to switch to such a model later on.<br>
+For migration between 2.x and 3.x branches (which should all be in the same<br>
+direction, though I'm not sure what direction is most appropriate here),</blockquote><div><br></div><div>Patches go from 2.x to 3.x typically.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
+changesets should be transplanted (not merged) in some other way. The<br>
+transplant extension, import/export and bundle/unbundle work equally well here.<br>
</blockquote><div><br></div><div>We will need to choose one and document how to use it. When you are ready to lock this down let me know and we can starting writing a new version of the dev FAQ.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
+Choosing this approach allows 3.x not to carry all of the 2.x history-since-it-<br>
+was-branched, meaning the clone is not as big and the merges not as<br>
complicated.<br>
+</blockquote><div><br></div><div>So just like it is now with svnmerge, right? That's fine as long as we continue to include the revision # in the commit so it is possible to reference the original commit on the other branch.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
The future of Subversion<br>
------------------------<br>
<br>
@@ -281,7 +323,9 @@<br>
I propose that the revision identifier will be the short version of hg's<br>
revision hash, for example 'dd3ebf81af43', augmented with '+' (instead of 'M')<br>
if the working directory from which it was built was modified. This mirrors<br>
-the output of the hg id command, which is intended for this kind of usage.<br>
+the output of the hg id command, which is intended for this kind of usage. The<br>
+sys.subversion value will also be renamed to sys.mercurial to reflect the<br>
+change in VCS.<br>
<br>
For the tag/branch identifier, I propose that hg will check for tags on the<br>
currently checked out revision, use the tag if there is one ('tip' doesn't<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">http://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div><br>