svn

Keine erforderlich, aber es wird empfohlen, die Richtlinien im Dev FAQ zu befolgen.

bzr

Es ist keine Einrichtung erforderlich, aber für wesentlich schnellere und speichereffizientere lokale Branches sollten Sie ein gemeinsam genutztes Repository erstellen, um alle Ihre Python-Branches zu speichern. Ein gemeinsam genutztes Repository ist eigentlich nur ein übergeordnetes Verzeichnis, das ein .bzr-Verzeichnis enthält. Wenn bzr eine Revision committet, sucht es vom lokalen Verzeichnis aufwärts im Dateisystem nach einem .bzr-Verzeichnis, um die Revision zu speichern. Durch das Teilen von Revisionen über mehrere Branches hinweg reduzieren Sie den verwendeten Speicherplatz. Tun Sie dies

cd ~/projects
bzr init-repo python
cd python

Nun sollten alle Ihre Python-Branches innerhalb von ~/projects/python erstellt werden.

Es gibt auch einige Einstellungen, die Sie in Ihre Datei ~/.bzr/bazaar.conf und ~/.bzr/locations.conf einfügen können, um Standardeinstellungen für die Interaktion mit Python-Code festzulegen. Keine davon ist erforderlich, obwohl einige empfohlen werden. Z.B. würde ich empfehlen, alle Commits mit GPG zu signieren, aber das könnte für Entwickler eine zu hohe Hürde sein. Außerdem können Sie standardmäßige Push-Speicherorte festlegen, je nachdem, wohin Sie Branches standardmäßig pushen möchten. Wenn Sie Schreibzugriff auf die Master-Branches haben, könnte dieser Push-Speicherort code.python.org sein. Andernfalls könnte es ein kostenloser Bazaar-Code-Hosting-Dienst wie Launchpad sein. Wenn Bazaar gewählt wird, sollten wir die Richtlinien und Empfehlungen festlegen.

Mindestens sollten Sie Ihre E-Mail-Adresse einrichten

bzr whoami "Firstname Lastname <email.address@example.com>"

Wie bei hg und git unten gibt es Möglichkeiten, Ihre E-Mail-Adresse (oder eigentlich fast jeden Parameter) pro Repository einzustellen. Dies geschieht mit Einstellungen in Ihrer Datei $HOME/.bazaar/locations.conf, die wie die anderen DVCSs ein Ini-ähnliches Format hat. Weitere Einzelheiten finden Sie in der Bazaar-Dokumentation, die für diese Diskussion meist nicht relevant sind.

hg

Minimal sollten Sie Ihren Benutzernamen festlegen. Tun Sie dies, indem Sie die Datei .hgrc in Ihrem Home-Verzeichnis erstellen und Folgendes hinzufügen:

[ui]
username = Firstname Lastname <email.address@example.com>

Wenn Sie Windows verwenden und Ihre Tools keine Unix-Style-Newlines unterstützen, können Sie die automatische Zeilenende-Übersetzung aktivieren, indem Sie Ihrer Konfiguration Folgendes hinzufügen:

[extensions]
win32text =

Diese Optionen können auch lokal für ein bestimmtes Repository eingestellt werden, indem <repo>/.hg/hgrc anstelle von ~/.hgrc angepasst wird.

git

Keine erforderlich. Git unterstützt jedoch eine Reihe von Funktionen, die Ihre Arbeit mit ein wenig Vorbereitung erleichtern können. Git unterstützt das Setzen von Standardwerten auf Arbeitsbereichs-, Benutzer- und Systemebene. Die Systemebene liegt außerhalb des Umfangs dieses PEP. Die Benutzerkonfigurationsdatei ist $HOME/.gitconfig auf Unix-ähnlichen Systemen, und die Arbeitsbereichskonfigurationsdatei ist $REPOSITORY/.git/config.

Sie können das Tool git-config verwenden, um Präferenzen für user.name und user.email entweder global (für Ihr System-Login-Konto) oder lokal (für einen bestimmten Git-Arbeitsbereich) festzulegen, oder Sie können die Konfigurationsdateien bearbeiten (die das gleiche Format haben wie im Mercurial-Abschnitt oben gezeigt).

# my full name doesn't change
# note "--global" flag means per user
# (system-wide configuration is set with "--system")
git config --global user.name 'Firstname Lastname'
# but use my Pythonic email address
cd /path/to/python/repository
git config user.email email.address@python.example.com

Wenn Sie Windows verwenden, möchten Sie wahrscheinlich die Präferenzen core.autocrlf und core.safecrlf mit git-config auf true setzen.

# check out files with CRLF line endings rather than Unix-style LF only
git config --global core.autocrlf true
# scream if a transformation would be ambiguous
# (eg, a working file contains both naked LF and CRLF)
# and check them back in with the reverse transformation
git config --global core.safecrlf true

Obwohl das Repository normalerweise eine .gitignore-Datei enthält, die Dateinamen angibt, die selten oder nie im VCS registriert werden sollten, haben Sie möglicherweise persönliche Konventionen (z.B. immer Log-Nachrichten in einer temporären Datei namens „.msg“ bearbeiten), die Sie angeben möchten.

# tell git where my personal ignores are
git config --global core.excludesfile ~/.gitignore
# I use .msg for my long commit logs, and Emacs makes backups in
# files ending with ~
# these are globs, not regular expressions
echo '*~' >> ~/.gitignore
echo '.msg' >> ~/.gitignore

Wenn Sie mehrere Branches verwenden, können Sie wie bei den anderen VCSs viel Speicherplatz sparen, indem Sie alle Objekte in einem gemeinsamen Objektspeicher speichern. Dies kann auch die Downloadzeit sparen, wenn die Ursprünge der Branches in verschiedenen Repositories lagen, da Objekte über Branches in Ihrem Repository geteilt werden, auch wenn sie in den Upstream-Repositories nicht vorhanden waren. Git ist sehr speicher- und zeiteffizient und wendet eine Reihe von Optimierungen automatisch an, sodass diese Konfiguration optional ist. (Beispiele sind weggelassen.)

svn

svn checkout http://svn.python.org/projects/python/trunk
cd trunk
# Edit some code.
echo "The cake is a lie!" > README
# Since svn lacks support for local commits, we fake it with patches.
svn diff >> commit-1.diff
svn diff >> patch-1.diff
# Upload the patch-1 to bugs.python.org.
# Receive reviewer comments.
# Edit some code.
echo "The cake is real!" > README
# Since svn lacks support for local commits, we fake it with patches.
svn diff >> commit-2.diff
svn diff >> patch-2.diff
# Upload patch-2 to bugs.python.org

bzr

bzr branch http://code.python.org/python/trunk
cd trunk
# Edit some code.
bzr commit -m 'Stuff I did'
bzr send -o bundle
# Upload bundle to bugs.python.org
# Receive reviewer comments
# Edit some code
bzr commit -m 'Respond to reviewer comments'
bzr send -o bundle
# Upload updated bundle to bugs.python.org

Die Datei bundle ist wie ein Super-Patch. Sie kann von patch(1) gelesen werden, enthält aber zusätzliche Metadaten, sodass sie an bzr merge übergeben werden kann, um einen vollständig nutzbaren Branch zu erzeugen, komplett mit Historie. Siehe unten im Abschnitt Patch-Überprüfung.

hg

hg clone http://code.python.org/hg/trunk
cd trunk
# Edit some code.
hg commit -m "Stuff I did"
hg outgoing -p > fixes.patch
# Upload patch to bugs.python.org
# Receive reviewer comments
# Edit some code
hg commit -m "Address reviewer comments."
hg outgoing -p > additional-fixes.patch
# Upload patch to bugs.python.org

Obwohl hg outgoing keine entsprechende Option hat, unterstützen die meisten Mercurial-Befehle das erweiterte Patch-Format von git über einen Befehl mit der Option --git. Dies kann in der Datei .hgrc eingestellt werden, sodass alle Befehle, die einen Patch generieren, das erweiterte Format verwenden.

git

Die Patches könnten auch mit git diff master > stuff-i-did.patch erstellt werden, aber git format-patch | git am kennt einige Tricks (leere Dateien, Umbenennungen usw.), die ein normaler Patch nicht verarbeiten kann. Git greift „Stuff I did“ aus der Commit-Nachricht auf, um den Dateinamen 0001-Stuff-I-did.patch zu erstellen. Siehe unten Patch Review für eine Beschreibung des git-format-patch-Formats.

# Get the mainline code.
git clone git://code.python.org/python/trunk
cd trunk
# Edit some code.
git commit -a -m 'Stuff I did.'
# Create patch for my changes (i.e, relative to master).
git format-patch master
git tag stuff-v1
# Upload 0001-Stuff-I-did.patch to bugs.python.org.
# Time passes ... receive reviewer comments.
# Edit more code.
git commit -a -m 'Address reviewer comments.'
# Make an add-on patch to apply on top of the original.
git format-patch stuff-v1
# Upload 0001-Address-reviewer-comments.patch to bugs.python.org.

svn

# Assume the change to revert is in revision 40
svn merge -c -40 .
# Resolve conflicts, if any.
svn commit -m "Reverted revision 40"

bzr

# Assume the change to revert is in revision 40
bzr merge -r 40..39
# Resolve conflicts, if any.
bzr commit -m "Reverted revision 40"

Beachten Sie, dass Sie, wenn die rückgängig zu machende Änderung die letzte war, einfach bzr uncommit verwenden können.

hg

# Assume the change to revert is in revision 9150dd9c6d30
hg backout --merge -r 9150dd9c6d30
# Resolve conflicts, if any.
hg commit -m "Reverted changeset 9150dd9c6d30"
hg push

Beachten Sie, dass Sie „hg rollback“ und „hg strip“ verwenden können, um Änderungen rückgängig zu machen, die Sie in Ihrem lokalen Repository committet, aber noch nicht an andere Repositories gepusht haben.

git

# Assume the change to revert is the grandfather of a revision tagged "newhotness".
git revert newhotness~2
# Resolve conflicts if any.  If there are no conflicts, the commit
# will be done automatically by "git revert", which prompts for a log.
git commit -m "Reverted changeset 9150dd9c6d30."
git push

svn

Subversion passt nicht sehr gut zu diesem Entwicklungsstil, da es keine „Branches“ gibt, wie sie in diesem PEP definiert sind. Stattdessen muss ein Entwickler entweder einen weiteren Checkout zum Testen eines Patches erstellen oder einen Branch auf dem Server erstellen. Bis zu diesem Zeitpunkt haben Core-Entwickler nicht den Ansatz „Branch auf dem Server“ zur Bearbeitung einzelner Patches verfolgt. Für dieses Szenario wird davon ausgegangen, dass der Entwickler einen lokalen Checkout des Trunks erstellt, um damit zu arbeiten.

cp -r trunk issue0000
cd issue0000
patch -p0 < __patch__
# Review patch.
svn commit -m "Some patch."
cd ..
rm -r issue0000

Eine andere Möglichkeit ist, nur zu einem Zeitpunkt einen einzigen Checkout laufen zu lassen und svn diff zusammen mit svn revert -R zu verwenden, um unabhängige Änderungen, die Sie möglicherweise vorgenommen haben, zu speichern.

bzr

bzr branch trunk issueNNNN
# Download `patch` bundle from Roundup
bzr merge patch
# Review patch
bzr commit -m'Patch NNN by So N. So' --fixes python:NNNN
bzr push bzr+ssh://me@code.python.org/trunk
rm -rf ../issueNNNN

Alternativ dazu, da Sie diese Änderungen wahrscheinlich in den Trunk committen werden, könnten Sie einfach einen Checkout durchführen. Dies würde Ihnen einen lokalen Arbeitsbaum verschaffen, während der Branch (d.h. alle Revisionen) auf dem Server verbleibt. Dies ähnelt dem SVN-Modell und ermöglicht Ihnen möglicherweise eine schnellere Überprüfung des Patches. In diesem Fall ist kein Push erforderlich.

bzr checkout trunk issueNNNN
# Download `patch` bundle from Roundup
bzr merge patch
# Review patch
bzr commit -m'Patch NNNN by So N. So' --fixes python:NNNN
rm -rf ../issueNNNN

hg

hg clone trunk issue0000
cd issue0000
# If the patch was generated using hg export, the user name of the
# submitter is automatically recorded. Otherwise,
# use hg import --no-commit submitted.diff and commit with
# hg commit -u "Firstname Lastname <email.address@example.com>"
hg import submitted.diff
# Review patch.
hg push ssh://alexandre@code.python.org/hg/trunk/

git

Wir gehen von einem Patch aus, der mit git-format-patch erstellt wurde. Dies ist eine Unix-mbox-Datei, die einen oder mehrere Patches enthält, die jeweils als RFC 2822-Nachricht formatiert sind. git-am interpretiert jede Nachricht als Commit wie folgt: Der Autor des Patches wird aus dem From:-Header übernommen, das Datum aus dem Date:-Header. Das Commit-Log wird durch Verketten der Betreffzeile, einer Leerzeile und des Nachrichtenkörpers bis zum Beginn des Patches erstellt.

cd trunk
# Create a branch in case we don't like the patch.
# This checkout takes zero time, since the workspace is left in
# the same state as the master branch.
git checkout -b patch-review
# Download patch from bugs.python.org to submitted.patch.
git am < submitted.patch
# Review and approve patch.
# Merge into master and push.
git checkout master
git merge patch-review
git push

svn

Aufgrund der Verwendung von svnmerge durch Python beginnen Änderungen mit dem Trunk (2.7) und werden dann in die Release-Version 2.6 gemerged. Um die Änderung in die 3.x-Serie zu übernehmen, wird die Änderung in 3.1 gemerged, korrigiert und dann in 3.0 gemerged (2.7 -> 2.6; 2.7 -> 3.1 -> 3.0).

Dies steht im Gegensatz zu einer Port-Forward-Strategie, bei der der Patch auf 2.6 angewendet und dann in neuere Versionen übernommen worden wäre (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  # 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  # revision 0002.
cd ../release30-maint
svnmerge merge -r 0002
svn commit -F svnmerge-commit-message.txt  # revision 0003.

bzr

Bazaar ist hier ziemlich unkompliziert, da es das manuelle Cherry-Picking von Revisionen unterstützt. Im Beispiel unten hätten wir eine Revisions-ID anstelle einer Revisionsnummer angeben können, aber das ist normalerweise nicht notwendig. Martin Pool schlägt vor: „Wir würden generell empfehlen, die Korrektur zuerst im ältesten unterstützten Branch vorzunehmen und sie dann zu den späteren Releases zu mergen.“

# Assume patch applied to 2.7 in revision 0000
cd release26-maint
bzr merge ../trunk -c 0000
# Resolve conflicts and make sure patch works
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://me@code.python.org/py3k

hg

Mercurial unterstützt, wie andere DVCS, den aktuellen Workflow von Python-Core-Entwicklern zum Backporting von Patches nicht gut. Derzeit werden Bugfixes zuerst in die Entwicklungs-Hauptlinie (d.h. Trunk) angewendet, dann in die Wartungs-Branches zurückportiert und bei Bedarf in den py3k-Branch vorwärts portiert. Dieser Workflow erfordert die Möglichkeit, einzelne Änderungen per Cherry-Picking auszuwählen. Mercurials Transplant-Erweiterung bietet diese Möglichkeit. Hier ist ein Beispiel für das Szenario mit diesem Workflow:

cd release26-maint
# Assume patch applied to 2.7 in revision 0000
hg transplant -s ../trunk 0000
# Resolve conflicts, if any.
cd ../py3k
hg pull ../trunk
hg merge
hg revert Misc/NEWS
hg commit -m "Merged trunk"
hg push

Im obigen Beispiel verhält sich Transplant ähnlich wie der aktuelle svnmerge-Befehl. Wenn Transplant ohne die Revision aufgerufen wird, startet der Befehl eine interaktive Schleife, die nützlich ist, um mehrere Änderungen zu transplantieren. Eine weitere nützliche Funktion ist die Option –filter, die zum programmatischen Ändern von Änderungen verwendet werden kann (z.B. könnte sie zum automatischen Entfernen von Änderungen an Misc/NEWS verwendet werden).

Alternativ zum traditionellen Workflow könnten wir das Transplantieren von Änderungen vermeiden, indem wir Bugfixes im ältesten unterstützten Release committen und diese Fixes dann in die neueren Branches mergen.

cd release25-maint
hg import fix_some_bug.diff
# Review patch and run test suite. Revert if failure.
hg push
cd ../release26-maint
hg pull ../release25-maint
hg merge
# Resolve conflicts, if any. Then, review patch and run test suite.
hg commit -m "Merged patches from release25-maint."
hg push
cd ../trunk
hg pull ../release26-maint
hg merge
# Resolve conflicts, if any, then review.
hg commit -m "Merged patches from release26-maint."
hg push

Obwohl dieser Ansatz die Historie nicht-linear und etwas schwieriger zu verfolgen macht, fördert er die Fehlerkorrektur über alle unterstützten Releases hinweg. Darüber hinaus skaliert er besser, wenn viele Änderungen zu backporten sind, da wir nicht nach den spezifischen Revisions-IDs suchen müssen, um zu mergen.

git

In Git hätte ich einen Arbeitsbereich, der alle relevanten Master-Repository-Branches enthält. Git cherry-pick funktioniert nicht über Repositorys hinweg; Sie müssen die Branches im selben Repository haben.

# Assume patch applied to 2.7 in revision release27~3 (4th patch back from tip).
cd integration
git checkout release26
git cherry-pick release27~3
# If there are conflicts, resolve them, and commit those changes.
# git commit -a -m "Resolve conflicts."
# Run test suite. If fixes are necessary, record as a separate commit.
# git commit -a -m "Fix code causing test failures."
git checkout master
git cherry-pick release27~3
# Do any conflict resolution and test failure fixups.
# Revert Misc/NEWS changes.
git checkout HEAD^ -- Misc/NEWS
git commit -m 'Revert cherry-picked Misc/NEWS changes.' Misc/NEWS
# Push both ports.
git push release26 master

Wenn Sie regelmäßig von einem bestimmten Branch mergen (anstatt Cherry-Picking zu betreiben), können Sie verhindern, dass ein bestimmter Commit versehentlich in Zukunft gemerged wird, indem Sie ihn mergen und dann rückgängig machen. Dies verhindert nicht, dass ein Cherry-Pick den unerwünschten Patch einbezieht, und diese Technik erfordert, dass alles blockiert wird, was Sie nicht mergen möchten. Ich bin mir nicht sicher, ob dies in diesem Punkt von svn abweicht.

cd trunk
# Merge in the alpha tested code.
git merge experimental-branch
# We don't want the 3rd-to-last commit from the experimental-branch,
# and we don't want it to ever be merged.
# The notation "^N" means Nth parent of the current commit. Thus HEAD^2^1^1
# means the first parent of the first parent of the second parent of HEAD.
git revert HEAD^2^1^1
# Propagate the merge and the prohibition to the public repository.
git push

svn

# Create branch.
svn copy svn+ssh://pythondev@svn.python.org/python/trunk svn+ssh://pythondev@svn.python.org/python/branches/NewHotness
svn checkout svn+ssh://pythondev@svn.python.org/python/branches/NewHotness
cd NewHotness
svnmerge init
svn commit -m "Initialize svnmerge."
# Pull in changes from other developers.
svn update
# Pull in trunk and merge to the branch.
svnmerge merge
svn commit -F svnmerge-commit-message.txt

Dieses Szenario ist unvollständig, da die Entscheidung für ein DVCS getroffen wurde, bevor die Arbeit abgeschlossen war.

svn

Um die mangelnden kostengünstigen Branches von svn auszugleichen, gibt es die Option „changelist“, um eine Datei mit einer einzelnen Changelist zu verknüpfen. Dies ist nicht so leistungsfähig wie die Möglichkeit, auf Commit-Ebene zu verknüpfen. Es gibt auch keine Möglichkeit, Abhängigkeiten zwischen Changelists auszudrücken.

cp -r trunk issue0000
cd issue0000
# Edit some code.
echo "The cake is a lie!" > README
svn changelist A README
# Edit some other code.
echo "I own Python!" > LICENSE
svn changelist B LICENSE
svn ci -m "Tell it how it is." --changelist B
# Edit changelist A some more.
svn ci -m "Speak the truth." --changelist A
cd ..
rm -rf issue0000

bzr

Hier ist ein Ansatz, der bzr shelf (jetzt ein Standardbestandteil von bzr) verwendet, um einige Änderungen vorübergehend beiseite zu legen, während Sie einen Umweg machen, um die Socket-Fehler zu beheben.

bzr branch trunk bug-0000
cd bug-0000
# Edit some code. Dang, we need to fix the socket module.
bzr shelve --all
# Edit some code.
bzr commit -m "Socket module fixes"
# Detour over, now resume fixing urllib
bzr unshelve
# Edit some code

Ein anderer Ansatz verwendet das Loom-Plugin. Looms können die Arbeit an abhängigen Branches erheblich vereinfachen, da sie sich automatisch um die Stapelabhängigkeiten kümmern. Stellen Sie sich Looms als einen Stapel abhängiger Branches (in der Loom-Terminologie „Threads“ genannt) vor, mit einfachen Möglichkeiten, sich im Stapel der Threads auf- und abzubewegen, Änderungen im Stapel zu nachfolgenden Threads zu mergen, Unterschiede zwischen Threads zu erstellen usw. Gelegentlich müssen oder möchten Sie Ihre Loom-Threads in separate Branches exportieren, entweder zur Überprüfung oder zum Commit. Höhere Threads beinhalten alle Änderungen in den unteren Threads automatisch.

bzr branch trunk bug-0000
cd bug-0000
bzr loomify --base trunk
bzr create-thread fix-urllib
# 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
# Edit some code
bzr commit -m "Socket module fixes"
bzr up-thread
# Manually resolve conflicts if necessary
bzr commit -m 'Merge in socket fixes'
# Edit me some more code
bzr commit -m "Now that socket is fixed, complete the urllib fixes"
bzr record done

Für Bonuspunkte nehmen wir an, jemand anderes behebt das Socket-Modul genau so, wie Sie es gerade getan haben. Vielleicht hat diese Person sogar Ihren Fix-Socket-Thread übernommen und nur diesen in den Trunk übernommen. Sie möchten in der Lage sein, seine Änderungen in Ihren Loom zu mergen und Ihren nun redundanten Fix-Socket-Thread zu löschen.

bzr down-thread trunk
# Get all new revisions to the trunk. If you've done things
# correctly, this will succeed without conflict.
bzr pull
bzr up-thread
# See? The fix-socket thread is now identical to the trunk
bzr commit -m 'Merge in trunk changes'
bzr diff -r thread: | wc -l # returns 0
bzr combine-thread
bzr up-thread
# Resolve any conflicts
bzr commit -m 'Merge trunk'
# Now our top-thread has an up-to-date trunk and just the urllib fix.

hg

Ein Ansatz ist die Verwendung der Shelve-Erweiterung; diese Erweiterung ist nicht in Mercurial enthalten, aber sie ist leicht zu installieren. Mit Shelve können Sie Änderungen auswählen, die Sie vorübergehend beiseite legen möchten.

hg clone trunk issue0000
cd issue0000
# Edit some code (e.g. urllib).
hg shelve
# Select changes to put aside
# Edit some other code (e.g. socket).
hg commit
hg unshelve
# Complete initial fix.
hg commit
cd ../trunk
hg pull ../issue0000
hg merge
hg commit
rm -rf ../issue0000

Mehrere andere Möglichkeiten, dieses Szenario mit Mercurial anzugehen. Alexander Solovyov hat auf der Mercurial-Mailingliste einige alternative Ansätze vorgestellt.

git

cd trunk
# Edit some code in urllib.
# Discover a bug in socket, want to fix that first.
# So save away our current work.
git stash
# Edit some code, commit some changes.
git commit -a -m "Completed fix of socket."
# Restore the in-progress work on urllib.
git stash apply
# Edit me some more code, commit some more fixes.
git commit -a -m "Complete urllib fixes."
# And push both patches to the public repository.
git push

Bonuspunkte: Nehmen wir an, Sie haben sich Zeit gelassen, und jemand anderes behebt den Socket-Fehler auf die gleiche Weise wie Sie gerade, und hat ihn in den Trunk aufgenommen. In diesem Fall schlägt Ihr Push fehl, da Ihr Branch nicht aktuell ist. Wenn der Fix eine Einzeiler war, ist die Wahrscheinlichkeit sehr hoch, dass er *genau* gleich ist, Zeichen für Zeichen. Git würde das bemerken, und Sie sind fertig; Git würde sie stillschweigend mergen.

Angenommen, wir haben nicht so viel Glück

# Update your branch.
git pull git://code.python.org/public/trunk master

# git has fetched all the necessary data, but reports that the
# merge failed.  We discover the nearly-duplicated patch.
# Neither our version of the master branch nor the workspace has
# been touched.  Revert our socket patch and pull again:
git revert HEAD^
git pull git://code.python.org/public/trunk master

Wie Bazaar und Mercurial hat git Erweiterungen zur Verwaltung von Patch-Stapeln. Sie können das ursprüngliche Quilt von Andrew Morton verwenden, oder es gibt StGit („stacked git“), das die Patch-Verfolgung für große Patch-Mengen in das VCS integriert, ähnlich wie Mercurial Queues oder Bazaar Looms.

bzr

Es wird sich ändern, aber nicht wesentlich. Bei der Erstellung des Wartungs-Branches werden wir einfach an den neuen Ort pushen, anstatt einen svn cp durchzuführen. Tags sind völlig anders, da sie in svn Verzeichnis-Kopien sind, aber in bzr (und ich nehme hg an) sind sie nur symbolische Namen für Revisionen auf einem bestimmten Branch. Das Skript release.py muss geändert werden, um stattdessen bzr-Befehle zu verwenden. Es ist möglich, dass wir aufgrund der Tatsache, dass DVCS (insbesondere bzr) Cherry-Picking und Merging gut beherrscht, die Wartungs-Branches früher erstellen können. Es wäre eine nützliche Übung, zu versuchen, eine Veröffentlichung von den bzr/hg-Spiegeln aus durchzuführen.

hg

Offensichtlich müssen Details, die spezifisch für Subversion in PEP 101 und im Release-Skript sind, aktualisiert werden. Insbesondere müssen der Release-Tagging- und der Wartungs-Branch-Erstellungsprozess modifiziert werden, um die Funktionen von Mercurial zu nutzen; dies wird bestimmte Aspekte des Release-Prozesses vereinfachen und rationalisieren. Zum Beispiel wird das Taggen und erneute Taggen einer Veröffentlichung zu einer trivialen Operation, da ein Tag in Mercurial einfach ein symbolischer Name für eine gegebene Revision ist.

git

Es wird sich ändern, aber nicht wesentlich. Bei der Wartungs-Branch werden wir einfach zum neuen Speicherort pushen, anstatt ein svn cp durchzuführen. Tags sind völlig anders, da sie in svn Verzeichniskopien sind, aber in git nur symbolische Namen für Revisionen sind, ebenso wie Branches. (Der Unterschied zwischen einem Tag und einem Branch besteht darin, dass Tags sich auf einen bestimmten Commit beziehen und sich nie ändern, es sei denn, Sie verwenden git tag -f, um sie zu verschieben. Der ausgecheckte Branch hingegen wird automatisch von git commit aktualisiert.) Das release.py-Skript muss geändert werden, um stattdessen git-Befehle zu verwenden. Mit git würde ich sofort einen (lokalen) Wartungs-Branch erstellen, sobald der Release-Ingenieur ausgewählt ist. Dann würde ich "git pull" ausführen, bis mir ein Patch nicht gefiel, dann wäre es "git pull; git revert hässlicher-patch", bis es so aussah, als ob das Vernünftigste wäre, abzuzweigen und "git cherry-pick" auf die guten Patches anzuwenden.