Fixed a few typos, and updated some of the Bazaar scenarios.
This commit is contained in:
Barry Warsaw
parent
2025481a4e
commit
1b5e100206
44
pep-0374.txt
44
pep-0374.txt
|
|
@ -40,7 +40,7 @@ someone with commit privileges on the master copy of Python). People
|
|||
who are not core developers but who wish to work with Python's
|
||||
revision tree, e.g. anyone writing a patch for Python or creating a
|
||||
custom version, do not have direct tool support for revisions. This
|
||||
can be quite a limitation, since these non-core developers cannot do
|
||||
can be quite a limitation, since these non-core developers cannot
|
||||
easily do basic tasks such as reverting changes to a previously
|
||||
saved state, creating branches, publishing one's changes with full
|
||||
revision history, etc. For non-core developers, the last safe tree
|
||||
|
|
@ -314,6 +314,13 @@ At a minimum, I would set up your email address::
|
|||
|
||||
bzr whoami "Firstname Lastname <email.address@example.com>"
|
||||
|
||||
As with hg and git below, there are ways to set your email address (or really,
|
||||
just about any parameter) on a
|
||||
per-repository basis. You do this with settings in your
|
||||
``$HOME/.bazaar/locations.conf`` file, which has an ini-style format as does
|
||||
the other DVCSs. See the Bazaar documentation for details,
|
||||
which mostly aren't relevant for this discussion.
|
||||
|
||||
|
||||
hg
|
||||
''
|
||||
|
|
@ -466,6 +473,11 @@ bzr
|
|||
bzr send -o bundle
|
||||
# Upload updated bundle to bugs.python.org
|
||||
|
||||
The ``bundle`` file is like a super-patch. It can be read by ``patch(1)`` but
|
||||
it contains additional metadata so that it can be fed to ``bzr merge`` to
|
||||
produce a fully usable branch completely with history. See `Patch Review`_
|
||||
section below.
|
||||
|
||||
|
||||
hg
|
||||
''
|
||||
|
|
@ -629,7 +641,7 @@ bzr
|
|||
bzr merge patch
|
||||
# Review patch
|
||||
bzr commit -m'Patch NNN by So N. So' --fixes python:NNNN
|
||||
bzr push bzr+ssh://trunk
|
||||
bzr push bzr+ssh://me@code.python.org/trunk
|
||||
rm -rf ../issueNNNN
|
||||
|
||||
Alternatively, since you're probably going to commit these changes to
|
||||
|
|
@ -735,17 +747,17 @@ the fix first in the oldest supported branch, and then merging it
|
|||
forward to the later releases."::
|
||||
|
||||
# Assume patch applied to 2.7 in revision 0000
|
||||
cd release26-main
|
||||
cd release26-maint
|
||||
bzr merge ../trunk -c 0000
|
||||
# Resolve conflicts and make sure patch works
|
||||
bzr commit -m'Backport patch NNNN'
|
||||
bzr push bzr+ssh://trunk
|
||||
bzr commit -m 'Back port patch NNNN'
|
||||
bzr push bzr+ssh://me@code.python.org/trunk
|
||||
cd ../py3k
|
||||
bzr merge ../trunk -r 0000
|
||||
# Same as for 2.6 except Misc/NEWS changes are reverted
|
||||
bzr revert Misc/NEWS
|
||||
bzr commit -m'Forward port patch NNNN'
|
||||
bzr push bzr+ssh://py3k
|
||||
bzr commit -m 'Forward port patch NNNN'
|
||||
bzr push bzr+ssh://me@code.python.org/py3k
|
||||
|
||||
|
||||
hg
|
||||
|
|
@ -874,7 +886,7 @@ appropriate configuration of the repository host. This is
|
|||
similar in concept to the existing sandbox in svn, although details
|
||||
of repository initialization may differ.
|
||||
|
||||
For non-developers, there are various more-or-less public-access
|
||||
For non-core developers, there are various more-or-less public-access
|
||||
repository-hosting services.
|
||||
Bazaar has
|
||||
Launchpad_,
|
||||
|
|
@ -986,7 +998,7 @@ to squirrel away some changes temporarily while you take a detour to
|
|||
fix the socket bugs.
|
||||
::
|
||||
|
||||
bzr branch bzr+svn://trunk bug-0000
|
||||
bzr branch trunk bug-0000
|
||||
cd bug-0000
|
||||
# Edit some code. Dang, we need to fix the socket module.
|
||||
bzr shelve --all
|
||||
|
|
@ -996,7 +1008,7 @@ fix the socket bugs.
|
|||
bzr unshelve
|
||||
# Edit some code
|
||||
|
||||
Another approach one might take uses the loom plugin. Looms can
|
||||
Another approach uses the loom plugin. Looms can
|
||||
greatly simply working on dependent branches because they
|
||||
automatically take care of the stacking dependencies for you.
|
||||
Imagine looms as a stack of dependent branches (called "threads" in
|
||||
|
|
@ -1008,11 +1020,11 @@ or commit. Higher threads incorporate all the changes in the lower
|
|||
threads, automatically.
|
||||
::
|
||||
|
||||
bzr branch bzr+svn://trunk bug-0000
|
||||
bzr branch trunk bug-0000
|
||||
cd bug-0000
|
||||
bzr loomify trunk
|
||||
bzr loomify --base trunk
|
||||
bzr create-thread fix-urllib
|
||||
# Edit some code. Dang, we need to fix the socket module.
|
||||
# Edit some code. Dang, we need to fix the socket module first.
|
||||
bzr commit -m "Checkpointing my work so far"
|
||||
bzr down-thread
|
||||
bzr create-thread fix-socket
|
||||
|
|
@ -1026,7 +1038,7 @@ threads, automatically.
|
|||
bzr record done
|
||||
|
||||
For bonus points, let's say someone else fixes the socket module in
|
||||
exactly the same way you did. Perhaps this person even grabbed your
|
||||
exactly the same way you just did. Perhaps this person even grabbed your
|
||||
fix-socket thread and applied just that to the trunk. You'd like to
|
||||
be able to merge their changes into your loom and delete your
|
||||
now-redundant fix-socket thread.
|
||||
|
|
@ -1226,8 +1238,8 @@ Case-insensitive filesystem support
|
|||
-----------------------------------
|
||||
|
||||
bzr
|
||||
Should be OK. I share branches between Linux and OS all the
|
||||
time. I've done case changes (e.g. bzr mv Mailman mailman) and
|
||||
Should be OK. I share branches between Linux and OS X all the
|
||||
time. I've done case changes (e.g. ``bzr mv Mailman mailman``) and
|
||||
as long as I did it on Linux (obviously), when I pulled in the
|
||||
changes on OS X everything was hunky dory.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue