git-svn-helpers

git-svn-Helfer ist eine Sammlung von Kommandozeilen-Tools, die stark vereinfacht mit git für SVN-Repositories.
Hauptziel der git-svn-Helfer ist es, die Einrichtung eines lokalen Git Repository nach einer bestehenden svn checkout ein "Kinderspiel".
Er geht auch mit einem einzigen git-svn-Repository für die Arbeit an mehreren Kassen von (in der Regel) verschiedenen Branchen und das Umschalten zwischen ihnen.
Die grundsätzliche Verwendung (Beispiel)
Zusammenfassung:
> Cd path / to / svn / Repo-
> Gitify
Hier ist eine Beispielsitzung:
> Cd / tmp
> Svn co https://svn.plone.org/svn/plone/plone.app.form/branches/1.1 plone.app.form
A 1.1 / setup.py
...
Checkt Revision 27.228.
> Cd plone.app.form
> Gitify
Kein Git Repository in /Users/tomster/.gitcache/ gefunden.
Initiieren Klonen in den Cache.
Analysieren von svn log ...
Das Klonen von https://svn.plone.org/svn/plone/plone.app.form/ r10593: 27.155 in /Users/tomster/.gitcache/
Initialisiert leer Git-Repository in /Users/tomster/.gitcache/plone.app.form/.git/
...
Git-Zweigs 'local / 1.1' folgt jetzt SVN-Zweig '1.1':
# Auf Zweig local / 1.1
nichts zu begehen (Arbeitsverzeichnis sauber)
> Git branch
* Local / 1.1
& Nbsp; Master
Ist Folgendes zu beachten:
& Nbsp; * gitify begrenzt das Klonen zu den Änderungen in der svn log des Pakets fuß (hier https://svn.plone.org/svn/plone/plone.app.form/) gefunden. Eine große Zeitersparnis, vor allem bei großen Repositories (wie plone.collective)
& Nbsp; * gitify schuf die git-Repository unter ~ / .gitcache nicht an Ort und Stelle
& Nbsp; * gitify erstellt eine lokale Niederlassung local / 1.1, die die (Fern-) SVN-Zweig 1.1 folgt und umgeschaltet, um sie
Mehrere auschecken
In der Praxis werden Sie oft mit verschiedenen lokalen Kopien eines bestimmten Repository, also am Stamm und an einem Funktions-Zweig zu arbeiten. Das ist, wenn die .gitcache Verzeichnis oben angelegt ins Spiel. Lassen Sie uns unsere bisherigen Kasse aus dem Weg und eine Wartung der Kasse, die Stamm folgt:
> Cd ..
> Mkdir Feature-Zweig
> Mv plone.app.form Feature-Zweig /
> Mkdir Wartung
> Cd Wartung /
> Svn co https://svn.plone.org/svn/plone/plone.app.form/trunk plone.app.form
Ein plone.app.form / setup.py
...
& Nbsp; U plone.app.form
Checkt Revision 27.228.
Was passiert, wenn wir gitify hier laufen ?:
> Cd plone.app.form /
> Gitify
Git-Zweigs 'local / trunk' folgt jetzt SVN-Zweig "Stamm":
# Auf Zweig lokalen / trunk
nichts zu begehen (Arbeitsverzeichnis sauber)
Beachten Sie, dass diese Operation ging viel schneller, wie wir sie jetzt haben, das bestehende git-Repository im Cache-Verzeichnis verwendet. Dies kann durch die Betrachtung der verfügbaren lokalen Niederlassungen jetzt nachgewiesen werden:
> Git branch
& Nbsp; local / 1.1
* Lokale / trunk
& Nbsp; Master
Vorsichtsmaßnahmen
"Recycling" .git auf diese Weise funktioniert (vielleicht überraschend) in der Praxis gut, aber Sie müssen die folgenden im Auge zu behalten:
Alle Kassen die gleiche Index!
Lassen Sie uns einen Blick darauf, was das bedeutet, beim Zurückwechseln in unseren Funktionszweig:
> Cd ../../feature-branch/plone.app.form/
> Git status
# Auf Zweig lokalen / trunk
# Geändert, aber nicht aktualisiert:
# (Verwenden Sie "git add / rm ..." zu aktualisieren, was begangen werden)
# (Verwenden Sie "git checkout - ...", um Änderungen im Arbeitsverzeichnis zu verwerfen)
#
# Geändert: docs / HISTORY.txt
...
# Gelöscht: plone / app / Form / KSS / Tests / test_kss.py
...
#
# Untracked Dateien:
# (Verwenden Sie "git add ...", um in das, was begangen werden sind)
#
# Plone / app / Form / Tests / test_kss.py
Wohah! Was passiert ist, dass .git zeigt jetzt auf Rumpf und somit der Status-Befehl zeigt den Unterschied zwischen dem, und unsere Branche als lokale Änderungen, denn das ist, was das Dateisystem darstellt. Wir können dies überprüfen, indem Sie Unterversionen Statusbefehl:
> Svn st

Puh! Alles in Ordnung! Aber was ist mit git tun? Wir arbeiten an Rumpf fertig und wollen zurück zu unserer Funktionszweig, aber der git-Index ist alles falsch ?! Ganz einfach: einfach erneut ausführen gitify:
> Gitify
Git-Zweigs 'local / 1.1' folgt jetzt SVN-Zweig '1.1':
# Auf Zweig local / 1.1
nichts zu begehen (Arbeitsverzeichnis sauber)
Im Grunde ist das alles, was Sie sich merken müssen, wenn Sie mit mehreren Kassen des gleichen Pakets: Immer laufen gitify beim Umschalten zwischen Check-out

Was ist neu in dieser Version :

• Die cannonical Repository ist jetzt in https://github.com/collective. [Rossp]
• Befestigen Sie das Handling beim Wechsel zu einem SVN-Zweig, die bereits Schwachkopf hat eine Zweigstelle für. [Rossp]

Was ist neu in Version 0.8:

• Stellen Sie mit dem Befehl init entlang folgen, wenn der SVN-Repository wurde wechselte zu einem anderen Zweig. Dank Calvin Hendryx-Parker für den Hinweis auf das Problem. [Tomster]

Was ist neu in Version 0.7:

• Verwenden Sie vollständige Kopien anstelle von symbolischen Links zu Arbeitskopien erstellen. Dies vermeidet das Problem der mit dem git und SVN-Repository synchron beim Arbeiten mit mehreren Kopien des gleichen Repository und das Risiko von Konflikten stark reduziert.
• Das bedeutet auch, dass der Abrufbefehl jetzt funktioniert nur auf der Cache ohne Änderungen an der Arbeitskopie (so dass es sicher über crontab ausführen, zum Beispiel)
• Ausführen gitify gegen eine Arbeitskopie im alten Stil eine Fehlermeldung erzeugt. Ein reines Löschen der Symlink und wieder laufen gitify Heilmittel, das jedoch.
• Ein weiterer Effekt ist, dass der Befehl init wird nun nur einmal pro Arbeitskopie benötigt (es erneut führen Sie den Befehl nach dem Umschalten zwischen verschiedenen Arbeitskopien desselben Repository ist nicht mehr erforderlich).
• gitify daher nicht mehr standardmäßig den Befehl init (ebenso weder git svn noch nichts zu tun w / o liefert eine explizite Aktion). Auch hat sich von gitify (Rücken) umbenannt, um init. [Tomster]
• Lassen Sie die Hilfe, --version holen Befehle außerhalb .svn Ordner [tomster]
laufen

Was ist neu in Version 0.5:

• Hinzugefügt gitify Update-Befehl, der eine git-svn rebase führt Betrieb für die aktuelle svn checkout sondern übernimmt auch unbelegten Lokal Änderungen gracelully (im Gegensatz zu git svn aber wie svn tut)
• die Protokollierungsmodul für Benutzer-Feedback nicht mehr zu verwenden. Diese Idee war nicht fehlgeleitet

Was ist neu in Version 0.4:

• Refactoring die Einstiegspunkte, benutzen Sie einfach gitify. Alle anderen Befehle sind jetzt Unterbefehle von gitify:
• gs-Commit mit gitify Push ersetzt
• gs-Abruf mit ersetzt gitify holen
• Hinzugefügt Nutzung und Hilfeausgabe für jeden Befehl.
• Entfernt die gs-Klon Einstiegspunkt, wie es immer nur zusammen mit der Haupt gitify Befehl trotzdem verwendet.
• Verwenden Sie die richtige Protokollierung statt nur den Druck auf stdout
• Hinzugefügt umfangreiche Tests, einschließlich Funktionstests, die das gesamte Update decken / COMMIT-Zyklus von Klonen eines SVN-Repository und begehen darauf zurück.

Was ist neu in Version 0.3.1:

• BUGFIX: Verwenden Sie keine benutzerdefinierte Aliase, wie sie kann nicht installiert werden. Dies löst http://github.com/tomster/git-svn-helpers/issues#issue/2
• BUGFIX: Explizit Liste elementtree als Abhängigkeit Dies löst http://github.com/tomster/git-svn-helpers/issues#issue/1)

Was ist neu in der Version 0.3 Beta:

• Hinzugefügt die gs-Commit-Befehl, der zurück zu begehen hilft svn und halten git und synchron svn

Was ist neu in der Version 0.2 Beta:

• Hinzugefügt die gs-Abrufbefehl, die Beibehaltung der Cache hilft up-to-date

Anforderungen :

• Python