8976
Comment:
|
← Revision 23 as of 2021-02-08 07:53:35 ⇥
9231
|
Deletions are marked like this. | Additions are marked like this. |
Line 6: | Line 6: |
|| `svn update` || Kopiert aus dem SVN alle Aenderungen in das lokale Verzeichnis. '''Achtung''': lokale (eigene) Aenderungen werden nicht gemeldet! || || `svn status -u` || Vergleicht Repo mit lokalen Verzeichnis || || `svn ci [file]` || Schreibt die lokalen Aenderungen in's SVN || || `svn 2cl` || Aktualisiert das Changelog. Anzeigen mit `less ChangeLog`. Nuetlzich um zu sehen was als letztes veraendert wurde. || || `svn diff <file>` || Zeigt Unterschiede zwischen lokalen und entfernen Repository an || |
|| `svn update` || Kopiert aus dem SVN alle Änderungen in das lokale Verzeichnis. '''Achtung''': lokale (eigene) Änderungen werden nicht gemeldet! || || `svn status -u` || Vergleicht Repo mit lokalem Verzeichnis || || `svn ci [file]` || Schreibt die lokalen Änderungen ins SVN || || `svn 2cl` || Aktualisiert das Changelog. Anzeigen mit `less ChangeLog`. Nützlich um zu sehen was als letztes veraendert wurde. || || `svn diff <file>` || Zeigt Unterschiede zwischen lokalen und entferntem Repository an || |
Line 12: | Line 12: |
|| `svn ps svn:keywords Id <file>` || Setzt keyword 'Id', damit die beim einchecken automatisch aktualisiert wird. Im File muss irgendwo `$Id$` angegeben sein || | || `svn ps svn:keywords Id <file>` || Setzt keyword 'Id', damit die beim Einchecken automatisch aktualisiert wird. Im File muss irgendwo `$Id$` angegeben sein || |
Line 22: | Line 22: |
Standartgemäss, wird svn mittels packaging manager [[sepp]] installiert. | Standardgemäss wird svn mittels packaging manager [[sepp]] installiert. |
Line 37: | Line 37: |
SVN kenn verschiedene Arten die Zugriffe zu steuern. | SVN kennt verschiedene Arten, die Zugriffe zu steuern. |
Line 43: | Line 43: |
== Was zu Wissen ist, bevor man mit svn arbeitet == | == Was zu wissen ist, bevor man mit svn arbeitet == |
Line 45: | Line 45: |
Es sollte nie auf dem Repository direkt gearbeitet werden. Das Repository gilt als "Master" für Projektdaten. Zu bearbeiteten Daten sollen von dem jeweiligen Benutzer auf ein persönliches Verzeichnuss | Es sollte nie auf dem Repository direkt gearbeitet werden. Das Repository gilt als "Master" für Projektdaten. Zu bearbeitende Daten sollen von dem jeweiligen Benutzer auf ein persönliches Verzeichnis kopiert werden. |
Line 54: | Line 54: |
Wenn ein stabiler Status erreicht wird, kann dieser'' getagt'' werden. Das ist im Grunde nichts anderes, als eine Kopie der aktuellen Version. Wenn zum Beispiel eine 1 Version steht, kann man diesen''tagen''. Im Trunk kann wie gewohnt weitergearbeiten werden. Falls die Version 1 benötigt wird, ist diese im''Tag''zu finden. Dies geschieht typischerweise, wenn ein Release gemacht wird. | Wenn ein stabiler Status erreicht wird, kann dieser ''getaggt'' werden. Das ist im Grunde nichts anderes, als eine Kopie der aktuellen Version. Wenn zum Beispiel eine 1. Version steht, kann man diesen ''taggen''. Im Trunk kann wie gewohnt weitergearbeitet werden. Falls die Version 1 benötigt wird, ist diese im ''Tag'' zu finden. Dies geschieht typischerweise, wenn ein Release gemacht wird. |
Line 59: | Line 59: |
Ein Projekt kann sich typischerweise aufteilen. Das heisst, das 2 Gruppen innerhalb des Projektes 2 unterschiedliche Ziele verfolgen. Zum Beispiel macht die eine Gruppe ein Bugfix und andere Gruppe organisiert das Projekt von Grund auf neu um. In diesem Fall ist es sinnvoll, dass die Bugfix-Gruppe einen Branch vom Projekt erstellt und darauf Arbeiten (Ebenfalls eine Kopie). | Ein Projekt kann sich typischerweise aufteilen. Das heisst, dass 2 Gruppen innerhalb des Projektes 2 unterschiedliche Ziele verfolgen. Zum Beispiel macht die eine Gruppe einen Bugfix und die andere Gruppe organisiert das Projekt von Grund auf neu um. In diesem Fall ist es sinnvoll, dass die Bugfix-Gruppe einen Branch vom Projekt erstellt und darauf arbeitet (ebenfalls eine Kopie). |
Line 66: | Line 66: |
HINWEIS: Auf der selben Ebene wie trunk und branches liegt auch''''' tags''''' {{http://svnbook.red-bean.com/nightly/en/images/ch04dia3.png}} | HINWEIS: Auf der selben Ebene wie trunk und branches liegt auch '''''tags''''' {{http://svnbook.red-bean.com/nightly/en/images/ch04dia3.png}} |
Line 72: | Line 72: |
Eine sehr gute Anleitungspage ist unter http://artis.imag.fr/~Xavier.Decoret/resources/svn/index.html zu finden. Die wichtigsten Anwendungen habe ich zusätzlich dokumentiert. | Eine sehr gute Anleitungsseite ist unter http://artis.imag.fr/~Xavier.Decoret/resources/svn/index.html zu finden. Die wichtigsten Anwendungen habe ich zusätzlich dokumentiert. |
Line 110: | Line 110: |
Dieser'''''Tag''''' zeigt die unterschiede, des aktuellen Verzeichnisses und alle Unterverzeichnisse. {{{svn diff --diff-cmd xxdiff-subversion}}} | Dieser '''''Tag''''' zeigt die Unterschiede des aktuellen Verzeichnisses und aller Unterverzeichnisse. {{{svn diff --diff-cmd xxdiff-subversion}}} |
Line 116: | Line 116: |
Sämtliche Änderungen, ab dem angegebenen Pfad, werden im Repository übernommen. -m für Massage/Änderungskommentrar mitgeben |
Sämtliche Änderungen ab dem angegebenen Pfad, werden im Repository übernommen. -m für Message/Änderungskommentar mitgeben |
Line 123: | Line 123: |
||svn info<<BR>> ||Ermitteln der aktuelle Version<<BR>> || | ||svn info<<BR>> ||Ermitteln der aktuellen Version<<BR>> || |
Line 136: | Line 136: |
||svn log<<BR>> ||Ermitteln der Änderungerungen seit der Erstellung des Branches<<BR>> || | ||svn log<<BR>> ||Ermitteln die Änderung seit der Erstellung des Branches<<BR>> || |
Line 140: | Line 140: |
||<style="vertical-align: top;">svn commit ||<style="vertical-align: top;">Wenn alles ok ist, kann die neue Verison commitet werden. || | ||<style="vertical-align: top;">svn commit ||<style="vertical-align: top;">Wenn alles ok ist, kann die neue Verison committet werden. || |
Line 146: | Line 146: |
Um ein Verzeichnis in ein Projet zu importieren, gibt es den import-Kommand. | Um ein Verzeichnis in ein Projekt zu importieren, gibt es den import-Kommand. |
Line 186: | Line 186: |
# Laut Google kann das mit resolve geloest werden: | # Laut Google kann das mit resolve gelöst werden: |
Line 190: | Line 190: |
# Anschliessend war ein Commit moeglich: | # Anschliessend war ein Commit möglich: |
Line 198: | Line 198: |
}}} | }}} === Revert === https://stackoverflow.com/questions/814433/how-do-i-return-to-an-older-version-of-our-code-in-subversion {{{ [daschil@tlX] $ svn update $ svn merge -r 150:140 . $ svn commit -m "Rolled back to r140" }}} |
SVN
Contents
- SVN
-
Handout
- Beschreibung
- Installation
- Was zu wissen ist, bevor man mit svn arbeitet
-
Anwendung
- Ein neues Repository erstellen (Instanz)
- Ein neues Projekt erstellen
- Check out
- Vergleichen (diff)
- Commit
- Einen neuen Branch erstellen
- Branch/Trunk aktualisieren
- Import (eines Verzeichnisses)
- Loginfos anschauen
- Ein tag erstellen
- Files/Verzeichnis löschen
- Files hinzufuegen
- Version / Timestamp
- Resolve
- Revert
Handout
CMD |
Beschreibung |
svn update |
Kopiert aus dem SVN alle Änderungen in das lokale Verzeichnis. Achtung: lokale (eigene) Änderungen werden nicht gemeldet! |
svn status -u |
Vergleicht Repo mit lokalem Verzeichnis |
svn ci [file] |
Schreibt die lokalen Änderungen ins SVN |
svn 2cl |
Aktualisiert das Changelog. Anzeigen mit less ChangeLog. Nützlich um zu sehen was als letztes veraendert wurde. |
svn diff <file> |
Zeigt Unterschiede zwischen lokalen und entferntem Repository an |
svn add <file> |
Nimmt ein neues File im SVN auf |
svn ps svn:keywords Id <file> |
Setzt keyword 'Id', damit die beim Einchecken automatisch aktualisiert wird. Im File muss irgendwo $Id$ angegeben sein |
svn log -v | less |
Changelog |
svn checkout https://systemvcs.math.uzh.ch:8000/sys_svn[/<path>] |
Kompletten Tree oder einzelnes Verzeichnis auschecken |
svn resolve <file/directory> |
If there is a conflict, set the source to be 'resolved' |
Cheat sheet GIT for SVN users
Beschreibung
Subversion (SVN) ist eine Open-Source-Software zur Versionsverwaltung von Dateien und Verzeichnissen.
Installation
Standardgemäss wird svn mittels packaging manager sepp installiert.
Eine sehr umfängliche und technische Dokumentation ist unter http://svnbook.red-bean.com/nightly/en/index.html zu finden.
Date - Store
SVN bietet 2 Möglichkeiten, die Versionierungsdaten zu speichern
- FSFS (Flatfile)
- Berkeley DB
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends
Da Berkeley DB nur einen Vorteil bringt bei sehr grosser Datenmenge, haben wir uns für FSFS entschieden.
Rechte
SVN kennt verschiedene Arten, die Zugriffe zu steuern.
- Unix - Filegruppen
- Writerfile
- LDAP / NIS+
Was zu wissen ist, bevor man mit svn arbeitet
Grundsätzliches
Es sollte nie auf dem Repository direkt gearbeitet werden. Das Repository gilt als "Master" für Projektdaten. Zu bearbeitende Daten sollen von dem jeweiligen Benutzer auf ein persönliches Verzeichnis kopiert werden.
Es wird in 3 Arten unterteilt
HINWEIS: Diese drei Ordner (trunk, branches, tags) müssen, sofern gewünscht, bei einem neuen Projekt neu angelegt werden
Trunk
Grundsätzlich wird im Trunk gearbeitet und entwickelt. Trunk wird auch als Head bezeichnet.
Tags
Wenn ein stabiler Status erreicht wird, kann dieser getaggt werden. Das ist im Grunde nichts anderes, als eine Kopie der aktuellen Version. Wenn zum Beispiel eine 1. Version steht, kann man diesen taggen. Im Trunk kann wie gewohnt weitergearbeitet werden. Falls die Version 1 benötigt wird, ist diese im Tag zu finden. Dies geschieht typischerweise, wenn ein Release gemacht wird.
An Tags werden nie gearbeitet. Ist dies ein Bedarf, sollte der Tag den Trunk bzw. in einen Branch kopiert werden.
Branch
Ein Projekt kann sich typischerweise aufteilen. Das heisst, dass 2 Gruppen innerhalb des Projektes 2 unterschiedliche Ziele verfolgen. Zum Beispiel macht die eine Gruppe einen Bugfix und die andere Gruppe organisiert das Projekt von Grund auf neu um. In diesem Fall ist es sinnvoll, dass die Bugfix-Gruppe einen Branch vom Projekt erstellt und darauf arbeitet (ebenfalls eine Kopie).
Siehe auch Branch best practice: http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/
http://www.technoids.org/svnmerge.html
Filestruktur
HINWEIS: Auf der selben Ebene wie trunk und branches liegt auch tags
Lebenswandel eines Projektes
Anwendung
Eine sehr gute Anleitungsseite ist unter http://artis.imag.fr/~Xavier.Decoret/resources/svn/index.html zu finden. Die wichtigsten Anwendungen habe ich zusätzlich dokumentiert.
Ein neues Repository erstellen (Instanz)
svnadmin create --fs-type fsfs /home/user/svn
In einem Repository können beliebig viele Projekte angelegt werden.
Ein neues Projekt erstellen
svn mkdir file:///home/user/svn/myProject -m 'Created myProject'
!!! Hinweis (Trunk, Branches, tags) müssen manuell erstellt werden !!!
svn mkdir file:///home/user/svn/myProject/trunk -m 'Created trunk dir'
svn mkdir file:///home/user/svn/myProject/branches -m 'Created branches dir'
svn mkdir file:///home/user/svn/myProject/tags -m 'Created tags dir'
Check out
svn checkout file:///home/user/svn/myproject A myproject/trunk A myproject/trunk A myproject/trunk/doc A myproject/trunk/doc/index.html A myproject/trunk/src A myproject/trunk/src/main.cpp A myproject/trunk/src/Makefile A myproject/trunk/bin Checked out revision 3.
Vergleichen (diff)
Dieser Tag zeigt die Unterschiede des aktuellen Verzeichnisses und aller Unterverzeichnisse. svn diff --diff-cmd xxdiff-subversion
Commit
svn commit -m 'Use a class to print hello world'
Sämtliche Änderungen ab dem angegebenen Pfad, werden im Repository übernommen.
-m für Message/Änderungskommentar mitgeben
Einen neuen Branch erstellen
Kommando |
Wozu |
svn info |
Ermitteln der aktuellen Version |
svn cp |
Kopieren der Quelle in den neuen branch |
svn switch |
Ändern des aktuellen committing points |
Branch/Trunk aktualisieren
FI: Es ist stark zu empfehlen, auf dem persönlichen Workspace zu mergen.
Kommando |
Wozu |
svn commit/update |
Aktualisiert den Branch im Repository und den lokalen Workspace |
svn log |
Ermitteln die Änderung seit der Erstellung des Branches |
svn info |
Ermittelt die aktuelle Head-Version |
svn merge |
Behebt die Differenzen zwischen Trunk und Branch |
svn status |
Check for conflicts |
svn commit |
Wenn alles ok ist, kann die neue Verison committet werden. |
Import (eines Verzeichnisses)
Um ein Verzeichnis in ein Projekt zu importieren, gibt es den import-Kommand.
svn import /path/to/project/ file:///home/user/svn/project/trunk -m 'Initial import'
Loginfos anschauen
Um die Kommentare und Änderungen anzusehen, kann das log-Kommando verwendet werden.
svn log file:///home/user/svn
Ein tag erstellen
Siehe branch erstellen.
Files/Verzeichnis löschen
svn delete file:///home/user/svn/project/trunk/temp -m 'no useful'
Files hinzufuegen
svn add newfile
Version / Timestamp
Im File muss ein Token vorbereitet werden: $Id$
- Das Token in SVN aktivieren
svn ps svn:keywords Id <file>
Resolve
24.6.19: CR hat das ansible Verzeichnis via svn update auf den neuesten Stand gebracht. Anschliessend einige wenige Files bearbeitet und wollte anschliessend ein svn commit machen. Dabei gab es eine Fehlermeldung:
[crose@tlX] $ svn commit svn: E155015: Commit failed (details follow): svn: E155015: Aborting commit: '/home/a/crose/svn/ansible/trunk/playbooks/roles/thinlinc/server/heartbeat-setup' remains in conflict # Laut Google kann das mit resolve gelöst werden: $ svn resolved /home/a/crose/svn/ansible/trunk/playbooks/roles/thinlinc/server/heartbeat-setup Resolved conflicted state of 'trunk/playbooks/roles/thinlinc/server/heartbeat-setup' # Anschliessend war ein Commit möglich: $ svn commit Sending trunk/hosts Sending trunk/playbooks/base-system.yml Deleting trunk/playbooks/roles/thinlinc/server/heartbeat-setup Transmitting file data ..done Committing transaction... Committed revision 4974.
Revert
[daschil@tlX] $ svn update $ svn merge -r 150:140 . $ svn commit -m "Rolled back to r140"