location: Diff for "svn"

Institute of Mathematics - PublicMathWiki:

Differences between revisions 14 and 23 (spanning 9 versions)
⇤ ← Revision 14 as of 2015-02-04 09:44:24 →
Size: 7895
Editor: crose
Comment:
← Revision 23 as of 2021-02-08 07:53:35 → ⇥
Size: 9231
Editor: eseide
Comment:
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 15: Line 15:
|| `svn resolve <file/directory>` || If there is a conflict, set the source to be 'resolved' ||
Line 21: Line 22:
Standartgemäss, wird svn mittels packaging manager [[sepp]] installiert. Standardgemäss wird svn mittels packaging manager [[sepp]] installiert.
Line 36: Line 37:
SVN kenn verschiedene Arten die Zugriffe zu steuern. SVN kennt verschiedene Arten, die Zugriffe zu steuern.
Line 42: Line 43:
== Was zu Wissen ist, bevor man mit svn arbeitet == == Was zu wissen ist, bevor man mit svn arbeitet ==
Line 44: 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 53: 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 58: 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 65: 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 71: 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 109: 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 115: 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 122: Line 123:
||svn info<<BR>> ||Ermitteln der aktuelle Version<<BR>> || ||svn info<<BR>> ||Ermitteln der aktuellen Version<<BR>> ||
Line 135: 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 139: 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 145: 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 173: Line 174:
svn ps svn:keywords Id install
}}}		 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 ===
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

  1. SVN
  2. Handout
    1. Beschreibung
    2. Installation
      1. Date - Store
      2. Rechte
    3. Was zu wissen ist, bevor man mit svn arbeitet
      1. Grundsätzliches
      2. Es wird in 3 Arten unterteilt
        1. Trunk
        2. Tags
        3. Branch
        4. Filestruktur
        5. Lebenswandel eines Projektes
    4. Anwendung
      1. Ein neues Repository erstellen (Instanz)
      2. Ein neues Projekt erstellen
      3. Check out
      4. Vergleichen (diff)
      5. Commit
      6. Einen neuen Branch erstellen
      7. Branch/Trunk aktualisieren
      8. Import (eines Verzeichnisses)
      9. Loginfos anschauen
      10. Ein tag erstellen
      11. Files/Verzeichnis löschen
      12. Files hinzufuegen
      13. Version / Timestamp
      14. Resolve
      15. 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'

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 http://svnbook.red-bean.com/nightly/en/images/ch04dia3.png

Lebenswandel eines Projektes

  • http://upload.wikimedia.org/wikipedia/commons/thumb/4/4e/Subversion_project_visualization.svg/800px-Subversion_project_visualization.svg.png

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

http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/[[http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/|http://www.technoids.org/svnmerge.html]]

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

http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/[[http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/|http://www.technoids.org/svnmerge.html]]

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

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"

PublicMathWiki: svn (last edited 2021-02-08 07:53:35 by eseide)