[samba & subversion] Working copy op samba share kan niet?

[Yggdrasil]

Hallo Tweakers,

Is het onmogelijk om een svn working copy te hebben die op een samba share staat i.p.v. lokaal?

Ik probeer al weken om op mijn werk een subversion systeem op te zetten. Nu zijn we een webdev buro dus willen we graag ontwikkelen op onze devserver en niet op onze pc's, i.v.m. een consistente ontwikkelomgeving met php-extensions en zo (liever geen wamp suggesties dus).

Het opzetten van de repo op een linux server is gelukt, incl authenticatie en authorisatie. De /var/www/ op de debian devserver is geshared via Samba, zodat alle ontwikkelaars erbij kunnen.

De ontwikkelaars moeten via TortoiseSVN op hun windows pc's checkouts en commits kunnen doen van bestanden die in hun persoonlijke map op die Samba share staan. En hier gaat het mis!

Het committen van een wijziging geeft de volgende error:

code:

Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
In directory 'W:\foobar\web\cms\modules\weblog\beeldenbank\popup_newitem'
Error processing command 'committed' in 'W:\foobar\web\cms\modules\weblog\beeldenbank\popup_newitem'
Can't move
'W:\foobar\web\cms\modules\weblog\beel...\launcher.php.svn-work'
to
'W:\foobar\web\cms\modules\weblog\beeldenbank\popup_newitem\...\
Toegang geweigerd.

Een zoektocht op google leverde weinig op, behalve wat vermeldingen over permissies en suggesties om de working copy lokaal te zetten. Als ik de commit doe via command-line op de devserver is er geen enkel probleem. Alleen wanneer de files via samba benaderd worden gaat het fout.

De samba share leest en schrijft als user en group www-data, en alle bestanden in die share zijn ook owned door www-data.www-data, met permissies 775. Nu maakt svn blijkbaar zijn bestanden aan als read-only om zo ongelukjes te voorkomen. Aan de error te zien kan svn zo'n read-only bestand niet verplaatsen of zo. Vreemd genoeg lukt me dat zelf wel via windows verkenner. Ik kan dan alles doen, read-only zetten, delete, move, etc.

Hier is de relevante sectie uit smb.conf:

code:

[Websites]
        comment = Websites
        path = /var/www
        read only = No
        create mask = 0664
        directory mask = 0775
        force user = www-data
        force group = www-data
        delete readonly = yes
        dos filemode = yes

Ik had verwacht dat de 'delete readonly' en 'dos filemode' regels effect zouden hebben, maar helaas niet...

Heeft iemand van jullie dit aan het werken? Dus, een working copy op een samba share gebruiken vanaf een windows pc? Alle tips zijn erg welkom want ik sta op het punt het op te geven

[Mr_x007]

wij gebruiken dit ook, bij ons zijn staan het volgende in de smb.conf

[ict]
path = /share
browsable = yes
valid users = @groep
read only = yes
create mask = 0775
force create mode = 0664
write list = +groep
force group = +groep
directory mask = 0775
force directory mode = 0775

dit gaat goed icm met tortoise

[Yggdrasil]

Bedankt Mr_x007,

Force create mode en force directory mode heb ik toegevoegd, en dat maakt veel verschil.
Imports en checkin/out werken nu zoals verwacht. Bedankt!

Hoe gaan jullie om met locking van binary files? svn gebruikt normaal gesproken de read-only attribute van een bestand om gebruikers te herinneren dat een file gelockt moet worden (als je de needs-lock property hebt ingesteld op een filetype). Negeren jullie die functie gewoon, ervan uitgaande dat gebruikers goed communiceren? Of heb je daar een workaround voor?

[Nick_S]

Even een ander puntje. SVN checkouts met Samba worden meestal afgeraden. Dit oa. door problemen met Samba file locking, svn:eol-style en het sharen van een working copy door meerdere gebruikers. Wat is er mis met de checkout lokaal te houden en met post-commit hooks te werken om working copies op de server up to date te houden?

Zie ook deze thread: http://svn.haxx.se/users/archive-2008-01/0874.shtml

[Yggdrasil]

Klopt. Die argumenten heb ik gelezen.

Naar mijn mening wordt het probleem echter wat overdreven.

eol-style problemen komen eigenlijk alleen voor als je cross-platform edit, dus files op dezelfde share zowel via windows (samba) als rechtstreeks via linux benaderd. Zolang je dat maar in de gaten houdt is er geen probleem. Ik heb daarnaast een bedrijfswijde subversion config file gemaakt, die voor alle tekst mime-types de eol-style op native zet (en daarnaast natuurlijk keyword expansion instelt, mime-types, en needs-lock properties zet).

File locking is tegenwoordig ook niet zo'n issue meer. Moderne samba's ondersteunen dezelfde locking types als lokale filesystems, dus daar heb ik geen problemen mee ervaren.

Het sharen van een working copy is inderdaad een terecht taboe. Dit gaat geheel tegen het principe van concurrent versiebeheer in. Dat doe ik dus ook bewust niet. Samba share betekend niet per definitie shared wc.

Nee, op het moment dat een developer gaat meewerken aan een project maakt ie op de samba share onder de directory van het project een subdirectory aan met zijn naam en checkt daarin de code uit. Die directory is dus van hem en ik vertrouw erop dat men niet in elkaars directory gaat klooien. Als je de webserver aanroept via http://developernaam.www.projectnaam.nl.test/ dan levert Apache (via mod_rewrite) de juiste persoonlijke working copy. Voorheen werkten we allen in dezelfde dir en benaderden die via http://www.projectnaam.nl.test/. Het enige wat nu nog geshared wordt, is de database.

Voor webdev is je methode (met post-commit hooks om de working copy op de server te updaten) niet erg handig vanwege de administratieve overhead. Het bouwen van een website (vooral via de RAD methode) vereist namelijk constant kleine stukjes coden en reloaden van pagina's om te kunnen testen of de css, html, php, xsl of whatever klopt. Zelfs als je bijna foutloos zou coden (en wie kan dat?) betekend dat nog constant checkins van code en functionaliteiten die half af zijn. En net zoveel log messages. Oftewel, het vervuilt je repos enorm, en de ontwikkelaars weten niet meer of een fout door zichzelf of door een ander veroorzaakt wordt. Ik zie liever checkins van werkende stukjes code, zoals het ontwikkelen van een functie en na testen inchecken, of het fixen van een bug en na testen weer inchecken.

Waarom ontwikkel je dan niet lokaal op je pc, vraag je je af? Simpelweg omdat we niet op elke pc een werkende en vooral identieke installatie van apache, php, pear, php-extensions en mysql willen aanhouden. Het levert teveel kans op verschillende configuraties op, en veel werk voor de part-time systeembeheerder.

[Nick_S]

_{Misschien een beetje offtopic, maar het probleem is toch al opgelost, dus wil ik er nog wel even op in gaan.}

Yggdrasil schreef op donderdag 31 juli 2008 @ 17:28:
Voor webdev is je methode (met post-commit hooks om de working copy op de server te updaten) niet erg handig vanwege de administratieve overhead. Het bouwen van een website (vooral via de RAD methode) vereist namelijk constant kleine stukjes coden en reloaden van pagina's om te kunnen testen of de css, html, php, xsl of whatever klopt.

Dit probleem ken ik. Wij "hebben" ook een paar webdevver's (html, css, js) en die weten "zeer slecht" om te gaan met versie beheer. Mede ook doordat niet elk punt in je issue tracking is weer gegeven. ("Normale" dev methode: issue gevonden, test case maken, test case faalt, code fixen, test case slaagt, code inchecken, 1 issue gefixt) Ik denk, dat het een beetje zaak is tussen zachte en harde developers. (Niet slecht bedoeld, ik hoop dat ik het duidelijk uitleg: verschil tussen een "stukje opmaak" of een "stukje functionaliteit" wat niet werkt)

Oftewel, het vervuilt je repos enorm, en de ontwikkelaars weten niet meer of een fout door zichzelf of door een ander veroorzaakt wordt.

Repo's "vervuilen" heb ik geen moeite mee, revisies zijn goedkoop. Je zou dan meer een soort webdev branch maken. Per ontwikkelaar of groep ontwikkelaars die elkaars code wel nodig hebben, en daar ook de communicatie voor hebben.

Waarom ontwikkel je dan niet lokaal op je pc, vraag je je af? Simpelweg omdat we niet op elke pc een werkende en vooral identieke installatie van apache, php, pear, php-extensions en mysql willen aanhouden. Het levert teveel kans op verschillende configuraties op, en veel werk voor de part-time systeembeheerder.

Daar zal ook een stuk verschil in liggen tussen webdev en echt ontwikkelen (als iemand een betere omschrijving heeft van het verschil, graag, ik vind het ook lullig klinken) Ik zou niet willen werken op een platform wat ik niet beheers, als Java webapplicatie ontwikkelaar: Applicatieserver, Contentrepository, Database, webservice backends, etc) Dat moet of lokaal kunnen draaien, of lokaal gestubt kunnen worden. (Of gemock'd in m'n unittests)

[Janoz]

Ik snap je argumentatie mbt de inrichting van jullie ontwikkelomgeving. Wat je ook zou kunnen doen is de gedeelde map verplaatsen. ipv dat je uitchecked naar een gesharde map laat je de website van een gesharde map lopen.

Pas apache zo aan dat de website vanaf een share wordt gehaald van een ontwikkelpc.