Der bisherige pauschale Lesezugriff auf alle svn repositories wird abgeschafft, daher muss die Rechtestruktur angepasst werden.

Wir wollen uns bei IN nicht mit einer zu feinen Rechte Granularitaet beschaeftigen. Wir vergeben daher Rechte Gruppenweise (alle in bel, alle in sd, alle von cosylab, alle vom cern, etc.) auf repositories (bel, fesa, sd, bbe).

Um dies sauber durchzuziehen muessen colaborationsprojekte in ein eigenes repository umziehen (bel/cosylab sowie bel/application/lsa).

Der groesste Knackpunkt werden Projekte sein die mit externen Partnern gemeinsam bearbeitet werden. Insbesondere Cosylab wird in Zukunft keinen Zugriff mehr auf das bel repository haben.

Repository	bel	sd	bbe	fsy	lsa	cosylab	cern	any
bbe	R	R	RW	RW	-	-	-	-
bel	RW	R	R	R	-	-	-	-
lsa	RW	R	R	RW	RW	-	-	-
cosylab	RW	RW	R	R	-	RW	-	-
fesa/device	RW	RW	RW	RW	-	-	-	-
fesa/framework	R	R	-	-	-	-	R	-
sd	R	RW	R	R	-	-	-	-

auf fesa/framework haben einzelne Personen schreibenden Zugriff.

Das umziehen von repositories bedingt, dass alle user einen commit machen, danach die Daten migriert werden und anschliessend die User sie von der neuen URL auschecken (alternativ ein svn switch wenn die user in svn bewandert sind).

Fragen

• Ziehen cosylab projekte nach abschluss um? Kann zu Problemen fuehren wenn cosylab spaeter daran weiterarbeitet
• Anknüpfend an die erste Frage: Könnte/Will man z.B. in fesa/device Rechte auf eine handvoll fixe unterordner vergeben (Z.B. auf device/class/cosylab oder device/driver/cosylab ?)
• haben alle GSI-Gruppen lesenden Zugriff aufeinander? Erleichtert ggf die arbeit, kann aber passwoerter die im SVN gespeichert sind offen legen.
• Frage von Solveigh: Ist es damit noch moeglich GSI-fremden auch schreibenden Zugriff auf branches zu geben? -- CH: technisch ja, praktisch aufgrund des Verwaltungsaufwandes nicht umsetzbar, da dann zu viele Einzelrechte vergeben werden muessen

Rueckmeldungen

• [Alex] Sieht sehr gut aus! O.k. meinerseits.

Diskussion 2012-06-04

Um die Zusammenarbeit zu foerdern wird authentifizierten Benutzern weiterhin ein lesender Zugriff auf alle Repositories gestattet.

Benutzer sollten sich im klaren sein, dass viele ihren Code lesen koennen. Daten die nicht veroeffentlicht werden sollen sind daher nicht im Versionskontrollsystem zu hinterlegt (z.B. Datenbankpasswoerter).

Es wird in Zukunft haeufiger Projekte geben, die sich nicht an den Abteilungsgrenzen orientieren. Grossprojekte (fesa, lsa) sollen ein eigenes Repository erhalten.

Sollte die Subversion Struktur sich in Artefaktnamen wiederfinden, so ist ArtifactNamingGuideline zu bedenken

Weiteres wird in einer Diskussion 2012-06-12 geklaert.