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!
Das müsste mein "Programm" machen. Tut es aber leider nicht und darauf habe ich keinen Einfluss :(
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
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.
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!
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.
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.
Also jeden Stand raus holen, das Script ändern und in einem neuen svn importieren.
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.
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.
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.
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.
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.
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
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.
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?
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.
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?
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?
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
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.
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
Ach das liebe Konfigmanagement.... Da haben dir die Kollegen eine schöne scheisse eingebrockt. Werden die alten Dokumentenstände nur in SVN gespeichert? Und müssen sie sich revisionssicher neu erstellt werden können? Muss das Generierungsskript im SVN liegen?
Franz schrieb: > 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. Dann muss derjenige, der Dir vorschreibt, diesen Umstand zu akzeptieren, halt auch akzeptieren, dass alte Dokumente nicht mehr erzeugt werden können. Alternative: Alte Dokumente müssen weiterhin mit dem alten Programm erzeugt werden. Wenn Du schreibst, dass Du bei einem DAX Konzern bist und irgendein Idiot seine Blödheit nun auf Dich abwälzt, würde ich an Deiner Stelle mit Kompetenz reagieren und AUF GAR KEINEN FALL das Versionshistorie zerstören und alte Daten manipulieren. Zumal die alten Versionen ja offensichtlich auch eine wichtige Rolle spielen, sonst müsstet ihr euch ja keinen Kopp machen, wie man es hinbekommt, mit dem neuen Programm auch alte Daten zu verarbeiten. Aber vielleicht bist Du ja auch ein Musterarbeitnehmer und widersprichst Deinem Chef nicht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.