Hintergrund
Im Sommer wurde im offiziellen BitBucket-Blog ein offizieller Blogbeitrag veröffentlicht, in dem das Ende der Unterstützung für Mercurial-Repositorys angekündigt wurde.
Die Einstellung von Mercurial erfolgt in zwei Schritten:
- Ab dem 1. Februar 2020 können Benutzer keine neuen Repositorys mehr erstellen.
- Ab dem 1. Juni 2020 können Benutzer Mercurial-Funktionen in Bitbucket oder über dessen API nicht mehr verwenden, und alle Mercurial-Repositorys werden gelöscht.
Die Gründe für diese Entscheidung sind mehr oder weniger klar, aber in meiner Arbeit verwende ich mehrere Mercurial-Repositorys (Mercurial hat mir immer besser gefallen, aber ich werde diese Frage außerhalb des Geltungsbereichs dieses Artikels belassen), die ich für die Umstellung auf GIT benötigte.
Eigentlich begann dieser Ort ...
Das problem
Die Entwickler und der Support von BitBucket boten verschiedene Optionen für eine solche Konvertierung an. Ich habe sie alle ausprobiert und gleichzeitig Tools von Drittanbietern ausprobiert, beispielsweise das
Importieren von Repositorys in GitHub.
Es stellte sich heraus, dass alle diese Tools die Namen von Dateien und Verzeichnissen verderben, die Zeichen im kyrillischen Alphabet enthalten, und ich habe eine Menge solcher Dateien (TK, Spezifikationen und andere ähnliche Dateien). Es ist lustig, dass Kommentare, die Kyrillisch enthalten, gut toleriert und nach der Migration angezeigt werden.
Ich habe im Internet Informationen gefunden, dass es in Mercurial Tools gibt (Schlüssel in der Repository-Konfigurationsdatei), mit denen Sie die Standard-Zeichenkodierung steuern können. Zum einen sind sie nur explizit enthalten, zum anderen gibt es kein Tool zum Konvertieren des vorhandenen Repositorys . Nun, ich habe nicht geprüft, wie diese Option bei der Migration mit vorgefertigten Tools hilft. Es ist zu spät, diesen Weg einzuschlagen.
Es gab keine Lust, manuell nach Problemdateien zu suchen und manuell nachzufüllen, daher musste ich ein wenig nach einer Lösung suchen.
Vielleicht ist das Übertragen eines Repositorys mit russischen Zeichen in Dateinamen auch für jemanden relevant, und mein Artikel wird ein wenig Zeit sparen.
Lösung
Grundsätzliches Vorgehen
- Nehmen Sie sich das Repository git@github.com: seewindcn / tortoisehg.git - es enthält das Plugin fixutf8, das nicht in der Hauptdistribution enthalten ist. Es wird weiterhin angenommen, dass sich die lokale Kopie im Verzeichnis D: \ Development \ tortoisehg befindet
- Erstellen Sie eine Kopie Ihres Mercurial-Repository, um den Hauptstandort nicht zu beschädigen. Weiterhin werden alle Befehle im Kopierverzeichnis ausgeführt.
- Korrigieren Sie die Datei- und Verzeichnisnamen mit dem Befehl D: \ Development \ tortoisehg \ hg.exe addremove -s 100
- Commit in Repository D: \ Development \ tortoisehg \ hg.exe commit -m "Dateinamen reparieren"
- Schalten Sie das hggit-Plugin ein - in der .hg \ hgrc-Datei, die Sie hinzufügen müssen
[Erweiterungen]
hggit = - Vorbereitungen für die Konvertierung in GIT - Erstellen Sie ein Master-Label mit dem Befehl D: \ Development \ tortoisehg \ hg.exe bookmark -r default master
- Erstellen Sie ein GIT-Repository in BitBucket
- Wir verpflichten uns zum git + ssh- Repository von hg push: //git@bitbucket.org: <user> / <reponame> .git ( Beachten Sie , dass dies reguläres hg verwendet, da der Klon von seewindcn nicht mit SSH arbeiten möchte)
- Wir überprüfen auf der BitBucket-Website, ob die kyrillischen Dateinamen nicht kaputt gehen
- Wir klonen das GIT-Repository für uns selbst, überprüfen die Dateinamen, führen einen Byte-Vergleich aller Dateien durch, erstellen das Projekt, testen
- Nach dem Build wird es wahrscheinlich eine Menge neuer Dateien geben, für die GIT einen Commit vorschlagen wird. Die .hgignore-Datei muss von Hand in .gitignore konvertiert werden. Glücklicherweise können Sie dies einmal tun und eine Datei für alle anderen Repositorys verwenden.
Infolgedessen ist es uns gelungen, den Hauptstandardzweig des ursprünglichen Mercurial-Repositorys mit der gesamten Commit-Historie an den Master des GIT-Repositorys und sogar mit Labels zu übertragen. Von den Minuspunkten stelle ich nur das völlige Fehlen von Informationen über Änderungen an den Dateien mit Kyrillisch in der Geschichte der Festschreibungen fest - es gibt Festschreibungen und es gibt nicht einmal Verweise auf Dateien mit Kyrillisch (der Rest der Dateien ist natürlich in perfekter Reihenfolge).
Im Allgemeinen konnte die Aufgabe als erledigt betrachtet werden, aber aus sportlichen Gründen war es für mich auch interessant, die verbleibenden Zweige zu übertragen.
Verzweigungsumbruch außer Standard
- Holen Sie sich eine Liste der Filialen hg Niederlassungen
- Für jede Branche
- Wechseln Sie zu hg up <branchname> branch
- Erstellen Sie ein Label (der Labelname darf nicht mit dem Namen des Zweigs übereinstimmen): hg bookmark -r <hgbranchname> <gitbranchname>
- Gießen Sie den Zweig in GIT hg push git@bitbucket.org: <user> / <reponame> .git
Es kann vorkommen, dass der Name des Zweigs auch das kyrillische Alphabet enthält. In diesem Fall weisen hg-Zweige krakozyabry auf. In diesem Fall habe ich eine visuelle hg-Workbench verwendet - zu einer Filiale gewechselt und dort ein Etikett erstellt.
Zu diesem Zeitpunkt kommt komplett Feng Shui.
Falls jemand Interesse hat, tiefer zu graben, dann gehe ich ...
Referenzliste