Forum: PC-Programmierung SVN - Alte Revision verändern


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo

Da SVN als Codeverwaltung auch unter Programmieren fällt, hoffe ich, 
dass mir hier jemand weiterhelfen kann.

Ich habe ein Programm, welches aus Daten, die in einem SVN Repository 
liegen, Dokumente erzeugt. Dabei werden auch Skripte verwendet, die 
ebenfalls im Repository liegen.

Man kann von Dokumenten sowohl die Head als auch ältere Versionen 
ausgeben lassen. Bei älteren Versionen werden die Skripte jeweils in der 
Version ausgeführt, welche identisch zum Dokument ist.

Eine neuere Version des Programms hat eine Variable, die bisher ein 
reiner Zahlenwert vorlag, in einen mit Buchstaben vermischten String 
verändert.
Auf das Programm habe ich keinen Einfluss, ich muss die Ändeurng 
akzeptieren.

Eines der alten Skripte kommt damit nicht zurecht und stürzt ab. Somit 
ist es aktuell nicht mehr möglich, die alten Dokumente zu erzeugen. Ich 
konnte das Skript zwar korrigieren, allerdings nützt das nichts für die 
alten Revisionen.

Ich suche daher eine Möglichkeit, das Skript in den alten Revisionen 
auszutauschen. Es würde ausreichen, die erste Version des Skripts mit 
der angepassten Variante zu ersetzen, alle Folgeänderungen dürfen 
übergangen werden.

Leider scheint so etwas von Haus aus nicht vorgesehen zu sein, da es den 
eigentlichen Gedanken hinter einer Codeverwaltung widerspricht.

Hat jemand einen Tipp für mich, wie man das Problem lösen könnte?

Vielen Dank!

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Lass das Skript nicht im SVN, sondern in einer ausgecheckten Revision 
laufen.

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das müsste mein "Programm" machen. Tut es aber leider nicht und darauf 
habe ich keinen Einfluss :(

von Jan (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
1. Du schreibst, das alte docu mit den alten Skripten erstellt wird. 
Warum stört dann eine Änderung der Versionskennzeichnung, die neuer ist?
2. Überleg dir genau, ob du wirklich willst, was du fragst. Das führt 
Versionsverwaltung ad absurdum.
3. Für sowas hilft nur die Trickkiste: expotier das Repositorium, 
impotier den Teil, der so bleiben kann, Check das neue Script ein, 
impotier den Rest ohne das alte Script.
Jan

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Svn kenne ich nicht so gut, aber bei cvs hätte ich mir jetzt die Datei 
aus dem rep geladen und versucht die Änderung dort einzubauen. Solange 
der Teil sich nicht geändert hat wäre die aktuelle Änderung dann überall 
drin. Ansonsten ist es etwas anstrengender weil es dann viele Stellen 
sind die man ändern muss.

Bei cvs geht das weil in der rep Datei alles drin ist, also jede 
Änderung und so weiter ist da drin vermerkt und das in Editor 
freundlichen Text.

Was auch gehen könnte ist das du im rep die Datei austauschst gegen eine 
neue in der die ganzen Versionen verfügbar sind. Wobei es halt keine 
Änderungen gibt über die Versionen.

Aber das ist nicht der Sinn einer Versionsverwaltung.

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist, dass für das alte Dokument das alte Skript ausgeführt 
wird.
Auf Grund der Programmänderung stürzt das Skript ab und es wird kein 
Dokument erzeugt. Dieses Verhalten kann ich nicht beeinflussen.

Ich habe schon befürchtet, dass ich das von Hand zu Fuss machen muss. 
Damit bin ich dann etliche Stunden beschätigt.

Wenn ich dich richtig verstehe, müsste ich:

1. Dump des Repository bis zu dem Zeitpunkt, in dem das Skript erstmalig 
hinzugefügt wurde.
2. An dieser Stelle das korrigierte Skript einbinden.
3. Den Rest mit svndumpfilter? filtern und einspielen.

Schaun wir mal, ob ich das hinbekomme.
Ich hab gehofft, es gäbe eine Möglichkeit vom bestehenden Repository aus 
die Änderungen zu machen. Das würde nicht so lange dauern.

Vielen Dank!

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Franz schrieb:
> 2. An dieser Stelle das korrigierte Skript einbinden.
> 3. Den Rest mit svndumpfilter? filtern und einspielen.

Dann funktionieren aber IIRC die vorhandenen Working Copies nicht mehr.

Besser wäre ein neuer Branch mit dem neuen Skript und alten Daten.

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du kannst das bestehende Repositorium nicht nachträglich ändern. Deshalb 
bleibt dir nichts anderes übrig als es zu exportieren. Die exportierten 
Daten sind dann, so das man sie editieren kann, sodass du nur das 
importieren kannst was du möchtest. Das geht in ein neues Repositorium. 
Und als Zwischenschritt kannst du dann dabei das Skript tauschen.
Mit svnadmin dump und load sollte das gehen.

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also jeden Stand raus holen, das Script ändern und in einem neuen svn 
importieren.

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So ähnlich hab ich es auch gemacht.
Im log nachgeschaut, wann das Skript geändert.
An den Stellen den dump unterbrochen, die commits angepasst und alles in 
einem neuen repository zusammengesetzt.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
2 lesenswert
nicht lesenswert
Was für merkwürdige Vorschläge. Man manipuliert ein 
Versionskontrollsystem nicht. Das ist indiskutabel. Man kopiert es auch 
nicht zu Manipulationszwecken um.

Du musst an einer alten Version was ändern? Branche von der alten 
Version und mach die Änderung.

Du hast irgend ein Scheißdrecksprogramm das mit dem Branch dann nicht 
zurechtkommt? Repariere das Programm.

Wenn du das nicht darfst dann verteile Arschtritte. Weil da hat jemand 
was grundsätzliches über Versionskontrollsysteme nicht verstanden:

Zusammengehörige Teile werden nicht über Versionsnummern sondern über 
Tags korreliert. Repariere die Dreckssoftware statt deine 
Versionskontrolle auszuhebeln.

von foobar (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Hör auf Hannes, das ist die einzig vernünftige Methode!

Die anderen Vorschläge sind Wahnsinn und enden im Chaos - kann man 
höchsten mal für Testzwecke machen, die damit erzeugten Ergebnisse 
dürfen die Werkstatt aber nie verlassen.

von Franz (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hannes, schon mal drüber nachgedacht, wie weltfremd deine Aussage ist?
Prinzipiereiterrei hilft mir nicht weiter.
Ich kann nicht mal so eben die Software einen DAX-Konzerns umschreiben.
Wenn da noch Erweiterungen von Dritten im Spiel sind, wirds richtig 
lustig.

Dein Vorschlag ist also, sich in die Ecke zu stellen, schlicht zu sagen, 
das System ist kaputt und warten, dass vielleicht mal in Jahren eine 
Lösung um die Ecke kommt?
Bis dahin werden Projekte nicht fertig und 7-stellige Beträge verbrannt?

Ja, es ist nicht schön. Aber in einem Unternehmen, in dem Geld verdient 
werden muss, braucht man Lösungen, mit denen man weiter kommt.

Danke an die, die mir geholen haben. Das System läuft wieder und ich 
melde mich aus diesem Thread ab.

von imonbln (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Franz schrieb:
> Hannes, schon mal drüber nachgedacht, wie weltfremd deine Aussage ist?
> Prinzipiereiterrei hilft mir nicht weiter.

Aber er hat Recht, eine Versionsverwaltung hat genau eine Aufgabe, und 
die Hebelst du aus, wenn du die History Fälscht. Je nach dem ob der Code 
auch Zertifiziert ist, kann das sogar ernste Konsequenzen bedeuten.

Franz schrieb:
> Ich kann nicht mal so eben die Software einen DAX-Konzerns umschreiben.
> Wenn da noch Erweiterungen von Dritten im Spiel sind, wirds richtig
> lustig.

Offensichtlich Doch, du Falscht ja auch die SVN Versionsverwaltung.

Franz schrieb:
> Bis dahin werden Projekte nicht fertig und 7-stellige Beträge verbrannt?

Wenn da 7-stellige Beträge dran hängen, um so besser dann wird es auch 
ein 5-stelliges Budget geben, denn Bug zu Fixen. Offensichtlich hast du 
da einen Mission kritischen Bug entdeckt und statt die Fahne zu heben 
und deiner Geschäftsführung reihen Wein einzuschenken, versuchst du 
einen Workaround bis es zum nächsten Update kommt.
Wenn du dich nicht traust zu sagen, "Houston we have a Problem" geh zum 
Betriebsrat und lass dir Helfen. Momentan tuts du alles, damit das 
Problem, das nach deiner Aussage 7-stellige Beträge verbrennt im Zweifel 
an dir hängen bleibt.
Denn wenn das ganze Toxisch wird, wird sich jeder dran erinnern, dass du 
damals das Update gemacht hast und es nicht für nötig befunden hast die 
Geschäftsführung zu informieren das ihr da eine 7-Stellige Wette am 
Laufen ist, das niemand das Problem bemerkt.

von Rolf M. (rmagnus)


Bewertung
3 lesenswert
nicht lesenswert
Franz schrieb:
> Hannes, schon mal drüber nachgedacht, wie weltfremd deine Aussage ist?

Ich finde, es ist schon was dran. Am Repository rumzupfuschen, um 
nachträglich alte Commits an ein verkorkstes Tool anzupassen, empfinde 
ich jedenfalls als äußerst unschön.

> Prinzipiereiterrei hilft mir nicht weiter.
> Ich kann nicht mal so eben die Software einen DAX-Konzerns umschreiben.

Was hat das damit zu tun, ob der Hersteller der Software im DAX ist? Und 
aus welchem Grund funktioniert es nicht mehr? Ist das ein Bug in der 
Software oder eine bewusste Inkompatibilität zur Vorgängerversion?

> Wenn da noch Erweiterungen von Dritten im Spiel sind, wirds richtig
> lustig.

Nun, wenn der Inhalt deines Repositorys zwingende Abhängigkeiten von 
eine bestimmten Version irgnedeines Tools hat und du ältere Stände noch 
brauchst, musst du halt die dazu passende alte Version des Tools 
ebenfalls vorhalten oder die alten Stände an die neue Software anpassen 
und als separaten Branch pflegen.

> Dein Vorschlag ist also, sich in die Ecke zu stellen, schlicht zu sagen,
> das System ist kaputt und warten, dass vielleicht mal in Jahren eine
> Lösung um die Ecke kommt?
> Bis dahin werden Projekte nicht fertig und 7-stellige Beträge verbrannt?

Gerade wenn so viel auf dem Spiel steht, würde ich nach einer sauberen 
Lösung suchen. Die von dir gewünschte ist übelstes Gefrickel.

: Bearbeitet durch User
von Peter (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Da es hier ja nur um das aushebeln der Versionsverwaltung geht, wurden 
wohl genug Möglichkeiten aufgezeigt.

Das sowas total daneben ist und gegen dem Sinn einer VK  ist, sollte 
wohl auch jedem klar sein.

von Mark B. (markbrandis)


Bewertung
1 lesenswert
nicht lesenswert
Hannes J. schrieb:
> Du musst an einer alten Version was ändern? Branche von der alten
> Version und mach die Änderung.

Genau. Was spricht dagegen es so zu machen, lieber Themenersteller?

von Peter (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Das ist ja eine erlaubte Art, die dann aber nur für die neuen Tags geht.
Der TO wollte aber, wenn ich ihn richtig verstanden habe, jede Version 
durch laufen lassen. Somit auch die für ihn defekten.
Und so ein Blödsinn geht dann auch nur mit einer Umgehung der 
Eigenschaft einer VK.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Peter schrieb:
> Was auch gehen könnte ist das du im rep die Datei austauschst gegen eine
> neue in der die ganzen Versionen verfügbar sind. Wobei es halt keine
> Änderungen gibt über die Versionen.

Wie Du schon zuvor erwähnt hast, arbeitest Du offenbar mit CVS. Dort 
sind im Repository alle Dateien genauso strukturiert wie in der 
Arbeitskopie. Dies ist ja auch eine sehr bekannte Unzulänglichkeit von 
CVS, da sich hiermit z.B. die Umbenennung einer Datei nicht ordentlich 
darstellen lässt.

Ein Subversion-Repository ist jedoch gänzlich anders strukturiert. Hier 
gibt es pro Commit eine Revision, die aus zwei neue Dateien, d.h. eine, 
in der alle geänderten Dateiinhalte gespeichert sind, und eben weitere 
mit den sog. Revision Properties, besteht. Da ein Commit in vielen 
Fällen mehrere Dateien umfasst, sind in solch einer Datei auch die 
Änderungen mehrerer Dateien enthalten. Die Metainformationen sind alle 
im Klartext (~ASCII) enthalten, aber die eigentlichen Dateiinhalte sind 
üblicherweise komprimiert in Binärform. Daher wäre es prinzipiell 
durchaus möglich, einen Commit bzw. eine Revision zu ersetzen, ABER 
Subversion speichert diese üblicherweise als Differenz vorherigen 
Commits/Revisions. Falls man also eine Datei auscheckt, die schon in 
fünf Revisions enthalten ist, wird intern die ursprüngliche Datei 
genommen und viermal gepatcht; die geschieht aber völlig transparent für 
den Anwender und ist sogar erstaunlich schnell.

Wenn man also im Repository eine Revision händisch ändern oder 
austauschen würde, bestünde die beträchtliche Gefahr, dass man damit 
alle nachfolgenden(!) Revisions beschädigt, die sich auf die geänderte 
Revision beziehen. Je weiter man in der Historie zurück geht, desto 
größer ist diese Gefahr. Hinzu kommt auch noch, dass solche Operationen 
wie Kopieren oder das Erzeugen von Branches und Tags "leichtgewichtig" 
sind, d.h. es werden hierbei nur Bezüge erstellt, aber keine 
Dateikopien. Durch eine manuelle Änderung einer alten Revision 
beschädigt man also auch alle offiziellen Releases usw..

Hinzu kommt auch noch, dass solch eine Manipulation bei bestehenden 
Arbeitskopien zunächst gar nicht auffällt, da hier viele wichtigen 
Informationen gecacht werden und sich damit natürlich auf den alten, 
nicht manipulierten Stand des Repositories beziehen. Es gibt für einen 
SVN-Client überhaupt keinen Grund, alte Revisions auf Aktualität zu 
prüfen.

Für den von Dir beschriebenen Anwendungsfall ist solch eine Manipulation 
also höchstgradig gefährlich.

Es gibt meines Erachtens nur einen einzigen Fall, in dem eine manuelle 
Manipulation eines Repositories möglich ist. Man kann einfach die 
neuesten Revisions wegschmeißen, indem man die current-Datei auf eine 
ältere Revision zeigen lässt. Ich habe dies schon einmal gemacht, 
unmittelbar nachdem ich wesehentlich einen riesigen Binärklumpen 
eingecheckt hatte und diesen nicht bis ans Ende aller Tage im Repository 
haben wollte. Aber Vorsicht: bevor man z.B. auf Revision <n> 
zurückdreht, muss man sicherstellen, dass alle Arbeitskopie maximal 
Revision <n-1> haben. Es ist nicht möglich, später mittels "svn update 
-r <n-1>" auf einen früheren Stand zurückzukehren, da Subversion sonst 
meldet: "no such revision <n>". BTDT.

Es gibt aber noch einen anderen Weg, "legal" in der Historie 
herumzupfuschen. Sog. Revision Properties, zu denen insbesondere auch 
die Checkin-Kommentare gehören, lassen sich mittels "svn propedit 
--revprop -r" ändern. Bei vielen Installationen wird jedoch mittels 
pre-revprop-change-Hook verhindert, dass jeder SVN-Nutzer solche 
Änderungen durchführen darf.

> Aber das ist nicht der Sinn einer Versionsverwaltung.

Nach reiner Lehrbuchmeinung stimme ich da durchaus zu. Es gibt aber 
durchaus gewichtige Gründe, warum doch händische Eingriffe in einem 
Repository unvermeidlich sind. Ein früherer Kollege, der in vielfacher 
Hinsicht nicht unbedingt als die hellste Kerze auf der Torte galt, 
führte manchmal abends ein rekursives CVS add mit anschließendem blindem 
Checkin aus. Am nächsten Morgen fand dann jeder dessen Dateileichen im 
Repository, d.h. temporäre Dateien usw.. Eines Tages führte er das aber 
nicht nur in seinem Arbeitsverzeichnis aus, sondern in der Wurzel seine 
C:-Laufwerks, so dass es einen 20GB großen Haufen Dateimüll gab. Der Typ 
war so unfassbar hohl, da er sich nicht einmal daran störte, dass 
TortoiseCVS dieses Verzeichnis nicht als bestehendes Arbeitsverzeichnis 
anerkannte, sondern er den Repository-Pfad noch einmal eingeben musste.

Glücklicherweise war ich (mit root-Rechten auf dem betreffenden Server) 
am nächsten Morgen recht früh im Büro und konnte den Schaden am 
Repository noch reparieren, bevor sich auch noch anderen Entwickler die 
Arbeitsverzeichnisse mit dem Datenmüll zustopften.

Und nach etlichen solcher Vorkommnisse wunderte sich dann der besagte 
Kollege, dass er zum Ende seines Projektes entlassen wurde. Außerdem 
fand er es eh schon doof von uns, dass er für keinen einzigen Server das 
Root-Kenntwort bekam. Warum wohl?

von Mark B. (markbrandis)


Bewertung
1 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Glücklicherweise war ich (mit root-Rechten auf dem betreffenden Server)
> am nächsten Morgen recht früh im Büro und konnte den Schaden am
> Repository noch reparieren, bevor sich auch noch anderen Entwickler die
> Arbeitsverzeichnisse mit dem Datenmüll zustopften.

Ach Du je. :-(

Können wir uns aber darauf einigen: Wenn alle Entwickler normal mit dem 
Repository arbeiten, dann sollte es keinerlei Notwendigkeit geben 
rückwirkend das Repository zu verändern?

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Man könnte das ganze Repository in ein git Repository importieren, und 
dann die Frage nochmals stellen ;)

Ich würde ein kleines Transformationstool schreiben, welches das alte 
Dateiformat für das neue Programm verdaulich macht.

Oliver

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite nicht nur mit CVS!
SVN habe ich noch nie benutzt.

Ich habe aber noch nie bei git, mercury oder so versucht was rückwirkend 
zu ändern. Drin ist drin. Und wenn wir solche Kerzen hätten würde das 
sehr schnell geklärt. Im Notfall wird das Backup wieder eingespielt.

Das umstellen auf git wäre das selbe wie SVN 1 Dateien raus ,ändern und 
SVN 2 wieder rein.
Gut es gibt auch umwandelt Tools dafür, aber die können die gewünschte 
Anpassung nicht machen.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Also meiner Meinung nach ergibt sich die Lösung aus diesem Satz:

Franz schrieb:
> Eine neuere Version des Programms hat eine Variable, die bisher ein
> reiner Zahlenwert vorlag, in einen mit Buchstaben vermischten String
> verändert.

Es gibt also mindestens zwei verschiedene Versionen des Programms. Eine 
davon kommt mit der älteren Version der Dokumente klar, eine mit der 
neueren. Wenn man kein neues Programm schreiben darf, welches die 
Unterscheidung zwischen dem alten und dem neuen Format durchführen kann, 
dann muss man eben weiterhin zwei verschiedene Versionen des Programms 
verwenden. Wirklich ideal ist diese Lösung auch nicht - aber sie ist 
immer noch hundertmal besser, als nachträglich in einem Repository an 
den Dateien herumzupfuschen.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.