[SVN] Meerdere checkouts combineren tot 1 project

[Erpenator2]

Beste Tweakers,

Ik heb een SVN server opgezet waarbij we een root project hebben. Binnen dit root project zijn er enkele mappen die met SVN gedeeld moeten worden en andere niet. Hieronder een kleine weergave:
/root/
/root/css/
/root/templates/
/root/code/
/root/images/

Nu is het de bedoeling dat gebruiker x bij alles kan en gebruiker y bij alleen /root/css/ /root/templates/ . Daarvoor heb ik rechten ingesteld op de server en het werkt. Het enige wat lastig is dat gebruiker y per map een checkout moet doen en moet committen (in bijvoorbeeld eclipse).

Gebruiker y heeft namelijk geen lees en schrijfrechten op de /root/ waardoor hij niet op de root kan uitchecken. Wanneer ik de gebruiker y deze lees rechten wel geef worden ook alle bestanden uit de map /code/ gedownload en dat is nu net niet de bedoeling.

Iemand een suggestie?

[Nick_S]

Mag gebruiker y deze bestanden niet lezen, of wil je ze niet in je checkout hebben?

In geval van dat 2de kun je met sparse checkouts werken.

code:

svn co file://tmp/root root --depth=empty
cd root
svn up css
svn up templates

[Erpenator2]

Gebruiker y mag ze niet lezen en ik wil de de mappen waar gebruiker y geen toegang toe heeft ook niet in de checkout hebben.

Is de optie die jij aanbiedt alleen het onzichtbaar maken van bepaalde mappen, maar zijn de bestanden op een andere manier nog wel te bekijken/ downloaden?

[ Voor 8% gewijzigd door Erpenator2 op 06-01-2010 12:32 ]

[Nick_S]

Ik heb geen idee. Ik heb het nog nooit hoeven te gebruiken. Bij ons is het of wel rechten over een heel project of niet. Waarom zou gebruiker y niet die map mogen lezen?

Je zou er even mee kunnen gaan experimenteren. Laat ons aub de resultaten weten.

[Soultaker]

Als het maar om één directory gaat die beperkte schrijftrechten heeft (/root/code) is het dan niet een beter idee om die in een aparte repository te stoppen (of in een aparte directory) zodat de gebruikers die daar wél toegang toe hebben 'm apart kunnen uitchecken? Eventueel kun je er een een external reference naar maken.

De gebruikers van /root/code moeten dan wel apart committen, maar wellicht is dat ook wel goed, als de code gescheiden moet blijven van de rest van de content (waar het op lijkt).

Overigens vind ik het raar om delen van één repository voor gebruikers af te schermen. Dat je schrijfrechten op subdirectory-basis kunt toekennen vind ik nog wel logjsch, maar is het niet vreemd dat gebruikers die geen volledige leesrechten hebben, wél de revisiegeschiedenis met commitberichten en dergelijke kunnen zien? En wat gebeurt er als een developer per ongeluk een file movet van /code naar /css? Kun je dat dan nog ongedaan maken zonder op svnadmin terug te grijpen? (Zelfs als je de file terugmovet, hebben gebruikers toegang tot de revisiegeschiedenis van /css lijkt me.)

Ik zou er dan persoonlijk liever voor kiezen om de geheime code helemaal in een aparte repository te stoppen. Daarmee voorkom je dat gebruikers indirect of per ongeluk toegang krijgen tot bestanden die ze niet mogen inzien. Met externals kun je de boel wel weer op een logische manier aan elkaar koppelen (al zul je inderdaad apart in elke repository moeten committen).

[ Voor 47% gewijzigd door Soultaker op 06-01-2010 14:45 ]

[Nick_S]

En als je nu leesrechten op root zet, maar weer afpakt voor code? Dus:

code:

[/root]
* = r
gebruikerx = rw
[/root/code]
* =
[/root/css]
gebruikery = rw

Wat gebeurt er dan als gebruikerx de root uitcheckt?

[Erpenator2]

De oplossing van Nick werkt! Heel erg bedankt. Heb het getest en ze krijgen bij een checkout alleen wat ze nodig hebben.

We hebben sowieso een rare setup. De svn checkout komt direct op een webserver terecht zodat nieuwe updates daar direct terecht komen. We zijn nu aan het experimenteren met hoe deze manier het gemakkelijkste werkt en of je er ook goed genoeg mee kunt samenwerken.