Subversion-Ladevorgang schlägt fehl, wenn „keine solche Revision vorhanden ist“

Ich versuche zu lernen, wie man ein Subversion-Repo migriert, und stoße auf ein Problem, das für mich keinen Sinn ergibt. Ich habe früher svndumpfilterein Unterprojekt aufgeteilt und einige Pfadpräfixe entfernt. Einige hundert Commits werden jetzt korrekt importiert, aber dann wird die folgende Fehlermeldung angezeigt:

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/build.properties ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

OK, so gehe ich in die Dump - Datei zu sehen Revisionen 19190 und 19098. Zu allererster Revision 19098 tut exist in der Dump - Datei und wurde ohne Probleme importiert. Revision 19190 ist eine Fusion. Im Jahr 19190 finden Sie hier die Informationen der letzten Datei, die das Problem zu verursachen scheint:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Verwirrenderweise ist die Revision 19100 in dieser gefilterten Datei NICHT vorhanden. Aber der Fehler bezieht sich nicht auf 19100, sondern auf 19098!

Was mache ich, um diese Datei zu laden?

Vielen Dank!

Ich habe diese Art der Aufteilung schon oft gemacht. Ich denke, es hängt alles davon ab, wie Sie den Filter verwenden und wie Sie die Dump-Datei anschließend verarbeiten. Persönlich musste ich neben dem Projektpfad auch den svn-Benutzer ändern und die Revisionen neu nummerieren. Damit Sie sehen können, was getan werden kann, finden Sie hier einen relevanten Teil meines Skripts.

grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

Was dort passiert, ist, dass ich zuerst herausfiltere, was ich brauche, die leeren Revisionen aus offensichtlichen Gründen lösche und sie neu nummeriere. Dies gibt schön geordnete Revisionen. Dann lösche ich den Stammpfad des Projekts, das in meinem Fall in der Form von Gruppe / Kunde war, weil in dem neuen Repo das keinen Sinn hat (stattdessen ist das Repo selbst Gruppe / Kunde auf Platte) - dies sind die ersten 2 Seds

Im Folgenden entferne ich den Import nicht benannter Verzeichnisse, von denen eines aus den beiden oben genannten Einträgen für das Gruppenverzeichnis und eines für das Hinzufügen des Gruppen- / Kundenverzeichnisses resultiert.

Schließlich habe ich den Autor gebeten, es durch ein neues zu ersetzen. Dies war auch etwas schwierig, da die Länge der Eigenschaftsdefinition aktualisiert werden musste.

Dann lade ich es hoch und repariere die Dateisystemberechtigungen. Beachten Sie die 2 kommentierten Chowns für Apache. In einigen Fällen benötigen Sie diese. Schließlich habe ich Apache zur Svn-Gruppe hinzugefügt.

Nun, ich hatte nie Zusammenschlüsse in meinen SVN-Repos, also musste ich mich nie um diese kümmern, um die Trennung zu erreichen. In Ihrem Fall würde ich mir vorstellen, dass der Quell-Revisionspfad nicht importiert wird und deshalb nicht gefunden wird, obwohl sich der Fehler über die Revision selbst beschwert. Die Faustregel in der SVN-Importdatei lautet, dass alles, worauf an einer Stelle verwiesen wird, bereits importiert worden sein muss, bevor es verwiesen wird. Möglicherweise haben Sie etwas herausgefiltert, das Sie nicht sollten, obwohl Sie es möchten, oder die Sicherungsdatei nicht richtig aktualisiert, um alle anderen von Ihnen vorgenommenen Änderungen wiederzugeben.

Wenn Sie die relevante Struktur Ihres ursprünglichen Repos, einschließlich des zusammengeführten Quellpfads, sowie Ihre Aufrufe mit Parametern angeben, kann ich Ihnen möglicherweise mitteilen, was Sie verpasst haben. Mein Geld ist auf der Quelle der Fusion.

Ich habe ein großartiges Tool svndumpsanitizer verwendet . Das Problem ist, dass die Struktur des Subversion-Repositorys zu kompliziert ist. Wenn sich svndumpfilter in Revision 10 befindet, kann nicht festgestellt werden, ob ein Knoten, den der Benutzer verwerfen möchte, an eine Position verschoben wird, die er in Revision 113 beibehalten möchte. Daher kann er nur den Knoten verwerfen , und bei der Revision 113 bricht es ab, weil es die Daten, die es benötigt hätte, bereits verworfen hat.

Svndumpsanitizer funktioniert anders. Es durchsucht die Knoten mehrmals, um festzustellen, welche Knoten tatsächlich beibehalten werden sollten. Nachdem festgestellt wurde, welche Knoten beibehalten werden sollen, werden nur diese Knoten in die Ausgangsdatei geschrieben. Schließlich wird - falls erforderlich - ein Commit hinzugefügt, das alle unerwünschten Knoten löscht, die aufbewahrt werden mussten, um das Repository nicht zu beschädigen.