frage zu CVS/Subversion

[HELLinG3R]

Ich sitze hier gerade vor dem Subversionartikel in der CT vom 23.08.2004.
Privat habe ich ein mittelgroßes Projekt mit 3 Entwicklern, momentan arbeiten wir gänzlich ohne Versionierungssystem.
Wenns änderungen gibt, fliessen die bei mir zusammen, ich erstelle ein Paket und verteile es an die Entwickler zurück.
Dazu ist es aber nötig, den Projektstand einzufrieren, d.h. wenn jemand mir änderungen schickt, kann dieser bis zum verteilen des packages nicht mehr weiterentwickeln.

Wenn es ein CVS/Subversion Repository gäbe, hätte man ja eine Zentrale version der daten und eine lokale arbeitskopie, an der man änderungen macht.

Was passiert aber, wenn 2 Entwickler gleichzeitig an einer Datei Programmieren?
wird dann die version des einen durch die des anderen überschrieben, jenachdem wer später absendet?
oder werden beide versionen zu einer neuen "Zusammengeführt", sodass beide änderungen enthalten sind?

[eagle]

Wenn zwei Entwickler die gleiche Datei bearbeiten muss die Datei "gemerged" (zusammengeführt) werden. Im Fall von CVS muss der Entwickler der als Zweiter die Änderungen "commited" diesen Merge durchführen.

eagle

[lisan]

Vieles wird automatisch ,,gemischt''. Wenn zwei leute allerdings an der gleichen stelle etwas aender oder das gleiche machen muss der der mergt auswaehlen was nun passieren soll.

In den dateien werden die stellen markiert.

[HELLinG3R]

also habe ich das eben richtig verstanden, dass subversion-commit automatisch mergt, wenn die änderungen sich nicht auf die gleichen codestellen beziehen.

zb.
ich programmiere an test.c in zeile 100
der andere in zeile 300

dann committen beide und das wars dann?

[lisan]

Ich habe mit subversion noch nicht die erfahrung aber ich stelle demnaechst um.

Also - zwei leute checken das projekt aus und bearbeiten beide die version 1.4 der datei foo.c.

Einer von beiden macht einen commit - alles super.
Der zweite der commitet wird aufgefordert erst ein update zu machen, da cvs sieht dass im cvs einen neue version liegt,

Der benutzer macht also nun ein update auf seine projekt mit der datei foo.c welche er ja auch veraendert hat.
Hier geschieht nun der merge.

Cvs zeigt an wo er mergen konnte und wo nicht.

Hat der benutzer nun alle evtl. konflikte per hand geloest kann er ein commit machen.

p.s. du kannst dir ein test projekt erstellen und damit ueben - bringt so einiges

[HELLinG3R]

okay, danke!

ich werds mal auf meinen server spielen und dann mal etwas testen, du hast recht, übung bringt am meisten.
ich habe nur nicht genau gewusst, was ich mir unter cvs (und konsorten) genau vorstellen muss und wie es funktioniert.
Danke für den Einblick!

[lisan]

Cvs handhabt nur dateien. Es ist mit cvs sehr schwer dateien umzubenennen ohne, dass ihre versionsgeschichte verloeren geht.
Ich rate dir daher zu subversion.

[HELLinG3R]

hm, ich lese hier grade das anwenderhandbuch zu subversion, es scheint tatsächlich sehr mächtig zu sein!

Allerdings drängt sich mir eine frage auf:
was passiert, wenn ich mein workdirectory so vermurkse, dass ichs nicht mehr zurücksichern kann?
überschreibt ein checkout die ganzen dateien mit einem bestimmten stand aus dem repository oder werden nur aktuellere heruntergezogen?
was passiert mit "dateileichen" die garnichtmehr im repository sind?

[eagle]

Man kann sich Versionstände von einem bestimmen Datum oder einer bestimmten Versionsnummer anzeigen lassen. Es sind in einer Versionskontrolle alle commited'en Änderungen gespeichert.

Wenn man eine bestimmte Datei ab einem bestimmten Versionsstand nicht mehr benötigt, dann kann sie mit cvs del entfernt werden. In allen alten Versionen wird diese Datei aber weiterhin existieren.

eagle

[HELLinG3R]

nein, was ich meinte, ist:
ich habe mein workdir so geschrottet und verpfuscht, ich will jetzt wieder eine "suabere" version vom server und neu anfangen zu programmieren, mit dem stand von, sagen wir, gestern.

[eagle]

Man kann sich Versionstände von einem bestimmen Datum oder einer bestimmten Versionsnummer anzeigen lassen.

Das bedeutet natürlich auch das du alle entsprechenden Versionen wieder auschecken und weiter bearbeiten kannst. Man kann auch unabhängig Versionstränge (Branch) weiterpflegen, dass ist Sinn einer Versionskontrolle .

eagle

[HELLinG3R]

also setzt ein erneuter checkout mein komplettes workdirectory (oder bestimmte teile davon) auf einen stand im repository 1:1 zurück?

[eagle]

Ja. Du solltest dir die Aufgaben der Befehle checkout , update und commit genauer ansehen.

eagle

[emge]

also setzt ein erneuter checkout mein komplettes workdirectory (oder bestimmte teile davon) auf einen stand im repository 1:1 zurück?

Ja, wobei man (zumindest bei CVS) wohl von einem update/get clean copy spricht. Letztendlich dürfte das aber genau das sein, was du machen willst. Im Zweifelsfalle kannst du immer noch das ganze vermurkste Verzeichnis löschen und nochmal eine richtiges checkout machen.

Grüße, Marco

[HELLinG3R]

okay, danke für die infos!
ich habe bisher nicht viel mit CVS am hut gehabt, darum komme ich mit den befehlen noch etwas durcheinander...

[lisan]

Mit jedem commit speichern cvs als auch subversion nur die differenzen ab. D.h. du kommt an jeden stand vor einem commit wieder heran.
Man kann auch wie eagle bereits sagte, tags setzen z.B. cvs 'tag alles_ok', dann kann irgendwer oder du das projket mit diesem tag auschecken.
'cvs co -r alles_ok'
Tags haben wie du sicher merkst den vorteil, dass es eine aussage zu dem stand mitgibt und man sich erinnert: aha, da war noch alles super.
Weiterhin gibts 'branches', das sind abzweigung von der hauptentwicklung. So koennen die gleiche datei oder dateien (es gibt hier einen branch tag und eine best. nummer, die anzeigt was zu einem branch gehoert) auf unterschiedeliche weise bearbeitet werden; die entwicklung laeuft parallel. Spaeter macht man dann meist einen merge und bringt den branch wieder auf den hauptzweig.

Ein schickes feature von subversion ist noch, dass man ein projekt aus den unterschiedlichsen branches, versionen, tags etc. von subprojekten oder modulen zusammenstellen kann, durch eine art verlinkung.

[zyta2k]

Ich empfehle dir mal (gnu-) arch anzuschauen.

Tolle Sache

http://www.gnu.org/software/gnu-arch/tu ... ucing_arch

[weedy]

nein, was ich meinte, ist:
ich habe mein workdir so geschrottet und verpfuscht, ich will jetzt wieder eine "suabere" version vom server und neu anfangen zu programmieren, mit dem stand von, sagen wir, gestern.

svn revert

oder

svn revert ([Datei|Verzeichnis]name)*

Du kannst Dir natürlich auch erstmal die Differenzen zwischen einer bestimmten Version und Deiner Arbeitsversion ansehen:

svn diff ([Datei|Verzeichnis]name)*

oder

svn diff -r versionsnr:BASE ([Datei|Verzeichnis]name)*

weedy.

Nachtrag:

svn help liefert:

Code: Alles auswählen

$ svn help
usage: svn <subcommand> [options] [args]
Type "svn help <subcommand>" for help on a specific subcommand.

Most subcommands take file and/or directory arguments, recursing
on the directories.  If no arguments are supplied to such a
command, it will recurse on the current directory (inclusive) by
default.

Available subcommands:
   add
   blame (praise, annotate, ann)
   cat
   checkout (co)
   cleanup
   commit (ci)
   copy (cp)
   delete (del, remove, rm)
   diff (di)
   export
   help (?, h)
   import
   info
   list (ls)
   log
   merge
   mkdir
   move (mv, rename, ren)
   propdel (pdel, pd)
   propedit (pedit, pe)
   propget (pget, pg)
   proplist (plist, pl)
   propset (pset, ps)
   resolved
   revert
   status (stat, st)
   switch (sw)
   update (up)

Subversion is a tool for version control.
For additional information, see http://subversion.tigris.org/

svn help revert:

Code: Alles auswählen

$ svn help revert
revert: Restore pristine working copy file (undo most local edits).
usage: revert PATH...

  Note:  this subcommand does not require network access, and resolves
  any conflicted states.  However, it does not restore removed directories.

Valid options:
  --targets arg            : pass contents of file ARG as additional args
  -R [--recursive]         : descend recursively
  -q [--quiet]             : print as little as possible
  --config-dir arg         : read user configuration files from directory ARG

und danach kannst Du mit svn update eine beliebige Version ziehen:

Code: Alles auswählen

$ svn help update
update (up): Bring changes from the repository into the working copy.
usage: update [PATH...]

  If no revision given, bring working copy up-to-date with HEAD rev.
  Else synchronize working copy to revision given by -r.

  For each updated item a line will start with a character reporting the
  action taken.  These characters have the following meaning:

    A  Added
    D  Deleted
    U  Updated
    C  Conflict
    G  Merged

  A character in the first column signifies an update to the actual file,
  while updates to the file's properties are shown in the second column.

Valid options:
  -r [--revision] arg      : ARG (some commands also take ARG1:ARG2 range)
                             A revision argument can be one of:
                                NUMBER       revision number
                                "{" DATE "}" revision at start of the date
                                "HEAD"       latest in repository
                                "BASE"       base rev of item's working copy
                                "COMMITTED"  last commit at or before BASE
                                "PREV"       revision just before COMMITTED
  -N [--non-recursive]     : operate on single directory only
  -q [--quiet]             : print as little as possible
  --diff3-cmd arg          : use ARG as merge command
  --username arg           : specify a username ARG
  --password arg           : specify a password ARG
  --no-auth-cache          : do not cache authentication tokens
  --non-interactive        : do no interactive prompting
  --config-dir arg         : read user configuration files from directory ARG

Im wesentlichen ist beinahe jede erdenkliche Hilfe über die SVN-Hilfefunktion auf der Commandline zu ermitteln.

weedy.