ABSTRACT: rcs (revision control system) wird vorgestellt AUDIENCE: junior admin SYSTEM: any unix SECTION: basic unix commands AUTHOR: mond COPYRIGHT: GNU Free Documentation Licence http://www.gnu.org/licenses/fdl.txt heute wieder mal ein kleines einfaches aber sehr praktisches werkzeug aus der unix schatztruhe: rcs. rcs steht fuer revesion control system und dient wie der name vermuten laesst zur kontrolle von "versionen". oft will man sich an einem file an dem man aenderungen durchfuehrt auch merken wer denn wann welche aenderungen vorgenommen hat. ist z.b. bei konfigurationsfiles nuetzlich die von mehreren administratoren verwaltet wird. oder einer website die von mehreren leuten gewartet wird. aber auch wenn man alleine an einem projekt arbeitet ist es nuetzlich einen zeitlichen verlauf seiner arbeit zu haben und auf den stand vor 2 wochen oder vor 2 monaten noch zugriff zu haben oder herausfinden zu koennen was man denn damals and dem file geaendert hat. haben wir ein file namens bla.txt dass wir via rcs verwalten wollen so speichert das rcs die inforamtionen ueber die verschiedenen versionene dieses files in einem file namenbs blabla.txt,v ein file dass auf ,v aendert ist also das versionfile. existiert in dem verzeichniss in dem das file liegt ein verzeichniss das RCS heisst so wird das ,v file dort abgelegt. das rcs ist wie ein hotel. in dieses hotel muss man "einchecken" und "aus-checken". mkdir RCS ci -u0.3 bla.txt das ci checkt das file in das rcs ein. das 0.3 waere dabei die anfaengliche versionsnummer. gibt man keine nummer an so faengt rcs bei 1.1 zu zaehlen an. bie jedem ci wird man nach ein oder mehreren zeilen an text gefragt die man als bearbeitungsnotiz in das rcs schreibt. damit man spaeter weiss warum man bestimmte aenderungen gemacht hat. nach einem "ci -u" wird das orginal file auf "readonly" geschalten. d.h. das writeable flag wird auch fuer den eigentuemer des files entfernt. die meisten editoren waren dann den user wenn er versucht dieses file zu editieren dass es erst auf +w geschalten werden muesste. das sollte man aber nicht tun weil man das file erst nach einem checkout bearbeite soll. co bla.txt macht ein checkout allerdings nur eine readonly kopie die man ebenfalls nicht bearbeiten sollte. sind meherere verschiedene versionen enthalten so kann auch eine bestimmte versionsnummer herauschecken. co -l bla.txt macht ein checkout des files das man dann auch bearbeiten darf und danach wieder einchecken sollte. das -l steht fuer lock und besagt dass derjenige der das file ausgecheckt hat es zur bearbeitung fuer andere gesperrt hat. ein ci bla.txt wuerde das file wieder einchekcen allerdings die aktuelle arbeitskopie entfernen. das verhindert zwar dass man mit dem file versehentlich arbeitet aber es ist noramlerweise nicht das was man will. ci -u bla.txt ist hier besser. es updated das RCS archiv mit einer neuen version aber hinterlaesst eine (readonly) kopie im arbeitsverzeichniss. das -u entfernt aber auch das lock. d.h. will man die kopie weiter bearbeiten muesste man sie erst wieder mit "co" aus-checken. will man nur waerend der arbeit einen zwischenstand im rcs abspeichern aber weiter an dem file editieren ohne neu "co -l" machen zu muessen macht man: ci -l bla.txt um tiparbeit beim bearbeiten von files die mit rcs bearbeitet werden zu sparen schreibt man sich oft auch gerne ein kleines script: z.b. /usr/bin/rcsjoe #!/bin/bash co -l $1 && joe $1 ; ci -u $1 das macht ein checkout des files ruft dann falls dies erfolgreich ist den editor joe auf und danach wieder ein checkin. das selbe geht natuerlich fuer jeden beliebigen anderen editor auch. z.b. rcsvi emacs hat, wie koennte es ander sein, support fuer rcs direkt eingebaut. joe als editor fuer rcs kontrollierte files hat einen kleinen nachteil: als root erlaubt es joe files die auf readonly sind ohne warnung zu bearbeiten. es besteht also die gefahr dass man files die eigentlich im rcs sind versehntlich editiert und beim naechsten co -l dann ueberschreibt. um das ueberschreiben in so einem falle zu verhindern kann man das script um einen check am anfang versehen: #!/bin/bash if (co -p $1 | diff - $1) ; then co -l $1 && joe $1 ; ci -u $1 else echo ======= ERROR ========= echo $1 is not identical with the last release fi das erlaubt den rcsjoe aufruf nur wenn die lezte version (die mit co -p auf stdout gepiped wird mit dem vorhandenen file identisch ist. rcs kann in die bearbeiteten files auch informationen ueber die versionsnummer und die bearbeitungslogfiles ablegen. steht irgendow im rcs file $Id$ so wird an dieser stelle vom rcs die aktuelle versionsnummer eingesetzt. steht irgendwo $Log$ so kommt an dieser stelle die loghistory. z.b: in einem C programm /* aktuelle version ist $Id$ * * $Log$ */ oder in einem shell script: # version $Id$ # # bearbeitungslog: # # $Log$ das utility rcs erlaubt noch einige modifikationen im verhalten von rcs. weitre tools: rcsdiff, rcsmerge und rcs2log bearbeiten mehrere leute ein file von mehren computern aus so ist rcs nicht mehr wirklich ausreichend. hier gibt es dann ein tool namens "cvs" (fuer concurent version system) das die speicherung von versionen auf einem zentralen server erlaubt. man kann dort auch ganze verzeichnisshirarchien ein und auschecken. etc.. EXERCISES: * erstelle ein text file und ein RCS verzeichniss. experimentiere mit ci und co befehlen. veraendere dazischen das file so dass eine versionshistory entsteht. * fueg $Id$ und $Log$ eintraege in das file REFERENCES: man rcs man co man ci