svn: committen nach groesserem Entwicklungsschritt
svn: committen nach groesserem Entwicklungsschritt
Hallo,
Ich bin dabei ein kleines Tool zu entwicklen, deren Grundbestandteil aus einem anderen Projekt besteht.
Dieses alte Projekt habe ich mit SVN importet und will es als Basisversion verwenden. Nun habe ich
schon etwas an dem Code weiterherumgewerkt, habe Dateien, sowie auch ganze Ordner voller Muell
herausgeloescht, neue Dateien (und Muell?) hinzugefuegt, etc, etc.. allerdings ohne das ganze
zwischenzeitlich zu "committen". Ich moechte nun aber den momentanen Stand der Dinge als "naechste
Version" des Urspruenglichen Codes einchecken ohne nun per Hand jede einzelne Datei zu pruefen ob
sie noch vorhanden ist, oder einzeln die neuen einzuchecken.
Wie mach ich das mit SVN? Gibt es da ein Script, wie geht man in so einem Fall am besten vor?
Ich bin dabei ein kleines Tool zu entwicklen, deren Grundbestandteil aus einem anderen Projekt besteht.
Dieses alte Projekt habe ich mit SVN importet und will es als Basisversion verwenden. Nun habe ich
schon etwas an dem Code weiterherumgewerkt, habe Dateien, sowie auch ganze Ordner voller Muell
herausgeloescht, neue Dateien (und Muell?) hinzugefuegt, etc, etc.. allerdings ohne das ganze
zwischenzeitlich zu "committen". Ich moechte nun aber den momentanen Stand der Dinge als "naechste
Version" des Urspruenglichen Codes einchecken ohne nun per Hand jede einzelne Datei zu pruefen ob
sie noch vorhanden ist, oder einzeln die neuen einzuchecken.
Wie mach ich das mit SVN? Gibt es da ein Script, wie geht man in so einem Fall am besten vor?
Re: svn: committen nach groesserem Entwicklungsschritt
Hallo,
ich programmiere mit NetBeans. Es stellt auch sehr schön die SVN Funktionen zur Verfügung. Veränderte Dateien werden farblich markiert, sogar geänderte/neue Codezeilen werden hervorgehoben. Evtl ist NetBeans ja eine Möglichkeit für dich (wenn deine Programmiersprache unterstützt wird)...
Ansonsten schau dir doch mal folgendes an:
http://code.google.com/p/nautilussvn/
Gruß
ich programmiere mit NetBeans. Es stellt auch sehr schön die SVN Funktionen zur Verfügung. Veränderte Dateien werden farblich markiert, sogar geänderte/neue Codezeilen werden hervorgehoben. Evtl ist NetBeans ja eine Möglichkeit für dich (wenn deine Programmiersprache unterstützt wird)...
Ansonsten schau dir doch mal folgendes an:
http://code.google.com/p/nautilussvn/
Gruß
Re: svn: committen nach groesserem Entwicklungsschritt
das geht doch mit jedem vernünftigen Svn-Client ( kdesvn, nautilussvn, smartsvn...), oder suchst du was für die Console ?Fabeltier hat geschrieben: Ich moechte nun aber den momentanen Stand der Dinge als "naechste
Version" des Urspruenglichen Codes einchecken ohne nun per Hand jede einzelne Datei zu pruefen ob
sie noch vorhanden ist, oder einzeln die neuen einzuchecken.
Gruß
gms
Re: svn: committen nach groesserem Entwicklungsschritt
Ja, hatte ich vielleicht vergessen dazu zu sagen, ich suche etwas fuer die Konsole.
Re: svn: committen nach groesserem Entwicklungsschritt
Also ein commit führt man in der Konsole mit dem folgendem Befehl aus:Fabeltier hat geschrieben:Ja, hatte ich vielleicht vergessen dazu zu sagen, ich suche etwas fuer die Konsole.
svn ci -m "Deine Log Meldung"
Wenn du deine aktuellen Änderungen als neuen "HEAD" commiten willst, reicht das aus. Ansonsten solltest du dir mal Branches anschauen.
Hier ist eigentlich alles sehr gut beschrieben.
http://svnbook.red-bean.com/en/1.5/index.htm
Gruß Athlux
Re: svn: committen nach groesserem Entwicklungsschritt
Hmm, naja, ich wuerde gerne einfach nur ein commit (wie von Dir angegeben) machen, nur hat sich eben auch der Filetree (enorm) veraendert zwischenzeitlich.
Dh. mein Problem besteht darin, dass ich die nun nicht mehr vorhandenen Files eben auch "weg" haben will (dazu muesste ich doch explizit vor dem commit erst
mal ein delete machen, oder?), dann sind einige neue Files dazugekommen (explizit jedes einzelne unter version control setzen, oder?), alles in allem ein Haufen
an Einzelaktionen, der doch auch irgendwie automatisiert gehen muesste... blos eben wie?
Welchen Vorteil wuerde mir hier ein Branch bringen, es sollte ja eigentlich nur die naechste "Version" sein und nicht ein separater branch?
Gibt es denn command line clients fuer svn, die soetwas in einem Schritt koennen?
Dh. mein Problem besteht darin, dass ich die nun nicht mehr vorhandenen Files eben auch "weg" haben will (dazu muesste ich doch explizit vor dem commit erst
mal ein delete machen, oder?), dann sind einige neue Files dazugekommen (explizit jedes einzelne unter version control setzen, oder?), alles in allem ein Haufen
an Einzelaktionen, der doch auch irgendwie automatisiert gehen muesste... blos eben wie?
Welchen Vorteil wuerde mir hier ein Branch bringen, es sollte ja eigentlich nur die naechste "Version" sein und nicht ein separater branch?
Gibt es denn command line clients fuer svn, die soetwas in einem Schritt koennen?
Re: svn: committen nach groesserem Entwicklungsschritt
Einen Client nutze ich nicht, ich werte meist direkt die Ausgabe von "svn st" aus.
Also normalerweise führe ich die Kopier/Verschiebeoptionen direkt per svn durch (z.B. "svn mv bla blubb"), damit svn auch Bescheid weiß. Zum Hinzufügen aller neuer Dateien werte ich die Ausgabe von "svn st" aus.
Vorher mal die Ausgabe von svn st kontrollieren, damit nichts unnötiges hinzugefügt wird.
Könnte man hier vielleicht auch mit den verschobenen Dateien machen, die sollten im Status mit "!" auftauchen. Aber bei der Aktion geht dann die Historie der Datei verloren. Vielleicht hat ja noch jemand eine Idee, wie man die Verschiebe/Kopieraktionen sinnvoller verarbeiten kann.
Also normalerweise führe ich die Kopier/Verschiebeoptionen direkt per svn durch (z.B. "svn mv bla blubb"), damit svn auch Bescheid weiß. Zum Hinzufügen aller neuer Dateien werte ich die Ausgabe von "svn st" aus.
Code: Alles auswählen
svn st | awk "/^?/{print \$2}" | xargs svn add
Könnte man hier vielleicht auch mit den verschobenen Dateien machen, die sollten im Status mit "!" auftauchen. Aber bei der Aktion geht dann die Historie der Datei verloren. Vielleicht hat ja noch jemand eine Idee, wie man die Verschiebe/Kopieraktionen sinnvoller verarbeiten kann.
MfG GoKi
:wq
:wq
Re: svn: committen nach groesserem Entwicklungsschritt
GoKi hat es ja schon schon gut beschrieben. Wenn man im Dateisytem direkt was ändert bekommt svn davon nichts mit. Daher am besten immerFabeltier hat geschrieben: Dh. mein Problem besteht darin, dass ich die nun nicht mehr vorhandenen Files eben auch "weg" haben will (dazu muesste ich doch explizit vor dem commit erst
mal ein delete machen, oder?), dann sind einige neue Files dazugekommen (explizit jedes einzelne unter version control setzen, oder?), alles in allem ein Haufen
an Einzelaktionen, der doch auch irgendwie automatisiert gehen muesste... blos eben wie?
direkt über die svn Befehle gehen.
Branches machen Sinn wenn du halbfertigen Code hast . Dann wird das einfach auf einen extra Branch commitet und der HEAD bleibt weiterhinFabeltier hat geschrieben: Welchen Vorteil wuerde mir hier ein Branch bringen, es sollte ja eigentlich nur die naechste "Version" sein und nicht ein separater branch?
kompilierbar. Soweit ich da bei dir jetzt verstanden habe reicht es bei dir ja aus einfach in den HEAD zu commiten.
Also mir sind keine bekannt. Das muss man dann halt entsprechend skripten. Beispielsweise mit awk wie oben.Fabeltier hat geschrieben: Gibt es denn command line clients fuer svn, die soetwas in einem Schritt koennen?
Gruß Athlux
Re: svn: committen nach groesserem Entwicklungsschritt
Hi,
vor jedem commit macht man ueblicherweise ein
Andernfalls kann es Dir naemlich passieren, dass Du gar nicht committen kannst, weil Dein Stand
nicht mehr mit dem aktuell im Repository befindlichen Stand uebereinstimmt.
Als Ergebnis dieses Updates erhaelst Du dann alle Aenderungen - und musst ggfs. Konflikte loesen.
Wenn alle Konflikte geloest sind - Sicherheitshalber nochmal ein - Deine Konfliktloesung
koennte ja wieder laenger dauern.
Wenn dann keine Aenderungen mehr zu Dir rueberkommen - und alles uebersetzbar und getestet ist - mach
am besten direkt im Wurzelverzeichnis das Du ausgecheckt hast ein
Ich persoenlich gehe zum beschreiben der Aenderungen immer die folgenden Schritte
1. Erzeuge eine Datei mit Informationen zu allen Aenderungen:
2. Beschreibe alle Aenderungen im einer Datei "commit.log" (unter Beruecksichtigung der Aenderungen in "svn.status")
3. Committe die Aenderungen:
Ciao
Stefan
vor jedem commit macht man ueblicherweise ein
Code: Alles auswählen
svn update
nicht mehr mit dem aktuell im Repository befindlichen Stand uebereinstimmt.
Als Ergebnis dieses Updates erhaelst Du dann alle Aenderungen - und musst ggfs. Konflikte loesen.
Wenn alle Konflikte geloest sind - Sicherheitshalber nochmal ein
Code: Alles auswählen
svn update
koennte ja wieder laenger dauern.
Wenn dann keine Aenderungen mehr zu Dir rueberkommen - und alles uebersetzbar und getestet ist - mach
am besten direkt im Wurzelverzeichnis das Du ausgecheckt hast ein
Code: Alles auswählen
svn commit -m "<hier die Aenderung beschreiben>"
1. Erzeuge eine Datei mit Informationen zu allen Aenderungen:
Code: Alles auswählen
svn status > svn.status
Code: Alles auswählen
vi svn.status commit.log
Code: Alles auswählen
svn commit --file commit.log
Stefan
Bürokratie kann man nur durch ihre Anwendung bekämpfen.
- schorsch_76
- Beiträge: 2612
- Registriert: 06.11.2007 16:00:42
- Lizenz eigener Beiträge: MIT Lizenz
Re: svn: committen nach groesserem Entwicklungsschritt
Also rein für die Konsole hab ich nichts. Ich nutze immer Rapid SVN . da siehst du auf einen Blick was Sache ist und ist auch schnell commitet.
Gruß
schorsch
Gruß
schorsch
Re: svn: committen nach groesserem Entwicklungsschritt
Schon klar, aber das ist doch genau die Frage dieses Threads??!!! WELCHE svn Befehle leisten das? Offensichtlich gibt es keine direktAthlux hat geschrieben:GoKi hat es ja schon schon gut beschrieben. Wenn man im Dateisytem direkt was ändert bekommt svn davon nichts mit. Daher am besten immerFabeltier hat geschrieben: Dh. mein Problem[...]... blos eben wie?
direkt über die svn Befehle gehen.
dafuer, sondern man muss zumindest einige derer in einem Script verwenden.. wie eben Goki es ja schon gut beschrieben hat.
Ich werde damit mal rumprobieren.
...eben, ich habe die letzten Jahre ClearCase und etwas git verwendet, svn ist mir noch neu, aber die grundlegende Idee von Branches scheint mir auchAthlux hat geschrieben: Branches machen Sinn wenn [...]
hier dieselbe, dh. in meinem Fall sehe ich eben keinen Sinn in einem separatem Branch.
Wie eingangs beschrieben, geht es mir nicht um einzelne Aenderungen von Dateien oder die generelle Benutzung fon svn, sondern um:
- eine groessere Anzahl Dateien und Ordner sind in der neuen Version nicht mehr vorhanden
- eine groessere Anzahl neue Dateien und Ordner sind dazugekommen
- manche Dateien sind von einem Ordner in einen anderen gegangen (gibt es dafuer ueberhaupt einen svn Befehl?)
...nun will ich einchecken und das automatisch erkennen lassen. Wie geht's?
Im allgemeinen Danke an Euch alle!!! Ich glaube ich sehe den Weg schon mehr oder weniger..
Re: svn: committen nach groesserem Entwicklungsschritt
Woher soll das arme svn denn wissen, welche Dateien gelöscht, welche verschoben, welche neu sind usw. wenn du ihm das nicht manuell mitteilstFabeltier hat geschrieben:Wie eingangs beschrieben, geht es mir nicht um einzelne Aenderungen von Dateien oder die generelle Benutzung fon svn, sondern um:
- eine groessere Anzahl Dateien und Ordner sind in der neuen Version nicht mehr vorhanden
- eine groessere Anzahl neue Dateien und Ordner sind dazugekommen
- manche Dateien sind von einem Ordner in einen anderen gegangen (gibt es dafuer ueberhaupt einen svn Befehl?)
...nun will ich einchecken und das automatisch erkennen lassen. Wie geht's?
Die Befehle hier erledigen genau das mas du brauchst:
svn cp: Datei duplizieren
svn mv: Datei von a nach b verschieben
svn rm: Datei löschen
svn add: Neue Datei bekannt machen
svn st / svn status: Hier siehst du wie oben schon beschrieben, was eigentlich so Sache ist. Welche Dateien wurden geändert oder gelöscht, welche sind unbekannt...
Formerly known as Trigger.
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams
Re: svn: committen nach groesserem Entwicklungsschritt
@ Armin: Super! Danke, damit duerfte es kein Problem sein..
Scripte) dazu in der Lage zu sein scheinen, diese offensichtlich fehlende Funktionalitaet nachzuimplementieren. Egal, bin nun wieder etwas schlauer,
danke nochmal!!!
Naja, warum ist das denn bei dem "armen svn" nicht auch gleich einfach mitimplementiert worden, wenn anscheinend grafische Frontends (bzw eigenearmin hat geschrieben: Woher soll das arme svn denn wissen, welche Dateien gelöscht, welche verschoben, welche neu sind usw. wenn du ihm das nicht manuell mitteilst
Scripte) dazu in der Lage zu sein scheinen, diese offensichtlich fehlende Funktionalitaet nachzuimplementieren. Egal, bin nun wieder etwas schlauer,
danke nochmal!!!
Re: svn: committen nach groesserem Entwicklungsschritt
Bitte was? Dir ist schon klar das die grafischen Frontends auch nicht mehr können sondern nur auf die API oder die svn Befehle zugreifen.Fabeltier hat geschrieben: Naja, warum ist das denn bei dem "armen svn" nicht auch gleich einfach mitimplementiert worden, wenn anscheinend grafische Frontends (bzw eigene
Scripte) dazu in der Lage zu sein scheinen, diese offensichtlich fehlende Funktionalitaet nachzuimplementieren. Egal, bin nun wieder etwas schlauer,
danke nochmal!!!
Da ist gar nichts zusätzlich implementiert worden.
Wenn du natürlich auf dem Dateisystem per Dateimanager wild Dateien löscht oder umbenennst hat das grafische Frontend naher genau die gleichen Probleme.
Gruß Athlux
Re: svn: committen nach groesserem Entwicklungsschritt
Hm, einer von uns beiden versteht was falsch.
Wie soll das ganze mit einem grafischen Frontend funktionieren? Das verschiebt dir auch nicht automatisch die Dateien, oder fügt neue dem Repository hinzu. Das ganze halt nur grafisch.
Naja, aber jetzt scheint es ja zu klappen. Von daher eh Wurst.
Wie soll das ganze mit einem grafischen Frontend funktionieren? Das verschiebt dir auch nicht automatisch die Dateien, oder fügt neue dem Repository hinzu. Das ganze halt nur grafisch.
Naja, aber jetzt scheint es ja zu klappen. Von daher eh Wurst.
Formerly known as Trigger.
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams
HP 8510p - Debian Sid
Mitglied des Debian-KDE-Teams
Re: svn: committen nach groesserem Entwicklungsschritt
da hast du absolut recht, nur wenn ich in einem besseren grafischen Frontend den Punkt "commit" auswähle, werden mir alle Änderungen, inklusive aller neuen Dateien und aller gelöschten Dateien angezeigt. Mittels "select all" und anschließendem "ok" habe ich dann alle diese Änderungen ruck-zuck committed, ohne für jede Datei einzeln ein "svn add" bzw "svn delete" absetzen zu müssen.armin hat geschrieben: Wie soll das ganze mit einem grafischen Frontend funktionieren? Das verschiebt dir auch nicht automatisch die Dateien, oder fügt neue dem Repository hinzu. Das ganze halt nur grafisch.
"kdesvn" (1.0.5) ist hier leider nicht ganz so komfortabel, dort gibt es zwar einen Button mit dem alle neuen Dateien für das "commit" ausgewählt werden können, für jede gelöschte Datei muß jedoch einzeln die entsprechende Checkbox angeklickt werden.
Gruß
gms
Re: svn: committen nach groesserem Entwicklungsschritt
Ich mach manchmal sowas hier:
svn status | awk '/^!/ {print "svn del "$2}; /^?/ {print "svn add "$2}' | sh
So nach der Art kann man dann noch mehr Fallunterscheidungen machen. Man kann das auch noch tunen, damit nicht für jede Datei ein extra svn Prozess gestartet wird.
Da hab ich noch ein awk-Script für.
svn status | awk '/^!/ {print "svn del "$2}; /^?/ {print "svn add "$2}' | sh
So nach der Art kann man dann noch mehr Fallunterscheidungen machen. Man kann das auch noch tunen, damit nicht für jede Datei ein extra svn Prozess gestartet wird.
Da hab ich noch ein awk-Script für.
Meine Whishlist
:wq!
:wq!