[linux-l] Re: Versionskontrollen

Steffen Dettmer steffen at dett.de
Mo Jan 29 19:43:56 CET 2007


* Rocco Rutte wrote on Mon, Jan 29, 2007 at 08:17 +0000:
> [ atomare Commits bei SVN ]
> > Ja, genau. Bei SVN wird das Rollback natürlich nur für *ein* Repository
> > gemacht, nämlich dass, wo der check-in gerade "aktiv war".

(BTW: da steht "für *ein* Repository")

> Wenn das in der Praxis so ist, dann ist das ein SVN-Bug und zwar ein
> großer, also so groß, dass es unbenutzbar ist.

Scheinbar nicht; gerade wurde von anderer Stelle bemerkt, dass man bei
zentralen SCMs auch oft nur ein Repository hätte.

CVS macht überhaupt keinen Rollback und ist in der Praxis prima
benutzbar.

> SVN behauptet transaktionsbasiert zu sein. D.h. alle User kriegen das 
> Ergebnis der Transaktion nur dann zu sehen, wenn alles vollständig 
> committet ist. D.h. solange ein großer Checkin nicht komplett durch ist, 
> bekommt niemand auch nur Teile davon zu sehen. Einen Abbruch muss der 
> Server handhaben und einen Rollback machen.

Geht ja so nicht. Siehe Volkers Beispiel. Man müsste einen zentralen
(ausgezeichneten/definierten) Server haben, der die Transaktionshoheit
hat, also der sagt, ob das nun als "ok" oder "fail" zählt. Könnte man
z.B. mit SVN machen, in dem dieser die Revisionsnummern aller
Repositories (atomar+isoliert) verwaltet. Dann könnte mindestens ein
Client nachfragen, bis zu welchem Stand Änderungen "genommen" werden
dürfen bzw. bei Abweichungen die Sandbox sperrt oder so.

> Ob sie das Repository jetzt global locken während einer Transaktion oder 
> erst dann, 

"das Repository"? Welches? Das aktive (also das, was ich gerade
einchecke)? Dann ist das ja meine Aussage, oder? Wobei mir noch nicht so
100% klar ist, ob ich in SVN sowas überhaupt mit einem Kommando rekursiv
abgrasen kann (also svn ci über mehrere Repositories).

Wie gesagt, wenn es nur ein Repository gibt, ist das einfach, klar
(dann ist's ja bei CVS wohl auch isoliert, nur das es kein Rollback
gibt).

> Und welche Art von Script/Befehl soll man hier benutzen müssen?

na, vielleicht

  for d in * ; do ( cd $d && svn ci ... ) done

oder sowwas. Ob und was man braucht hängt natürlich davon ab, wie die
checkouts liegen. Das Beispiel würde bei mir in der Firma funktionieren
(wenn man "." sonderbehandelt, fehlt ja oben und ist bei uns auch
nochmal eine checkout). Das Skript macht aber find und filtert und noch
paar Kleinigkeiten. 

Früher hatten wir eine andere Struktur, da war das komplizierter und
hatte (mehr) logische Schwächen. Die "alles Nebeneinander" hat immer
noch Schwächen: Man kann ein Modul nicht in zwei verschiedenen Versionen
benutzen und taggen (z.B. mit release oder branchtag). Das geht mit CVS
einfach nicht. Also, rein logisch nicht. Da müsste man ja die aktuelle
"Sicht" des Projektes (systems) auf das Modul mit im Tag haben, um das
beim Auschecken auswählen zu können. Na gut, dass sind advanced topics.
Aber soweit kommt man scheinbar mit den anderen SCMs [SVN, hg] gar nicht
erst :) (ausser vielleicht mit GIT und Darcs, darüber hatten wir ja noch
nicht soweit diskutiert, und letzteres soll ja eh für grosse Projekte zu
langsam sein).

Ach so, und falls einer ne Idee hat, wie man ein Modul in zwei
verschiedenen Versionen benutzen und taggen kann, bitte hier mal
verraten :) Auch eine SVN-Idee wäre interessant; da hat man ja erstmal
das gleiche Problem. 

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.





Mehr Informationen über die Mailingliste linux-l