[SVN/PHP] direct project vanuit repos aanspreken met apache

[Helox-in-a-box]

Het idee is het volgende:

als version control wordt subversion gebruikt, op de clients staan apache en tortoiseSVN. De client update zn source en gaat aan het werk, testen dient dan te worden gedaan op de client met de daar geinstalleerde apache.
Als de client klaar is met z'n code, commit hij de code, de verandering wordt dan dus in de repos gezet. Apache moet dan gelijk de nieuwste versie pakken (of vanuit de repos, of repos moet em automatisch exporteren).

Kheb op google, google groups, subversion projecten en GoT af zitten struinen maar kennelijk heeft niemand hier nog aan gedacht ofzo want kom nix tegen wat hier op lijkt.

Ik zoek dus "iets" om een stap over te slaan, namelijk de stap tussen als de client commit en dat apache de nieuwste versie serveert. Normaal gesproken dien je het project te updaten(indien checkout) of de exporteren(geen .svn dirs) op de webserver en dan is de nieuwste versie pas online.

Hoop dat het een beetje duidelijk is

hier mn groups post (int engels):
http://groups.google.com/...b73e%40posting.google.com

[Helox-in-a-box]

kick, misschien iemand die hetzelfde probleem heeft met CVS? of een soortgelijke oplossing weet voor CVS?

[Verwijderd]

Bij CVS is het mogelijk scripts uit te laten voeren zodra er iets ingecheckt wordt. In een recent project waar ik aan meegewerkt heb, gebruikten we dat om LaTeX documenten automatisch te laten compileren zodra ze ingecheckt werden.

In vervolg hierop; je kunt een script schrijven dat automatisch de export naar Apache uitvoert. Ik neem namelijk aan dat SVN deze mogelijkheid ook wel biedt.

(Vraag me overigens niet naar de details, want iemand anders beheerde de CVS server bij ons )

[dingstje]

En wat wou je doen als twee clients werken aan dezelfde file? Als ze allebei comitten en vervolgens weer checkouten zal dat goed gaan, maar als je die stap overslaat heb je een probleem denk ik.

[Creepy]

dingstje schreef op 17 augustus 2004 @ 20:14:
En wat wou je doen als twee clients werken aan dezelfde file? Als ze allebei comitten en vervolgens weer checkouten zal dat goed gaan, maar als je die stap overslaat heb je een probleem denk ik.

Eeh nee? Dan wordt de file ge-merged? Overigs check je geen losse file uit in SVN, maar een compleet project. Daarna update je lokaal je files vanuit de repository of commit je je wijzigigen naar de repository.

SVN ondersteunt hooks scripts. Hiermee kan je dus een bepaalde actie laten uitvoeren bij bijv. een commit. Hoe dit werkt staat mooi allemaal uitgelegd in het SVN book dat met nog geen 5 minuten google werk snel te vinden is

Voor de luiaards onder ons: http://svnbook.red-bean.c...02.html#svn-ch-5-sect-2.1

[dingstje]

Maar dan laat je hem niet meer automatisch de wijzigingen op de clients uitvoeren? Het lijkt me nogal gevaarlijk om automatich te mergen terwijl de user nog bezig is...

[Verwijderd]

Hè?

Als je een file commit die gewijzigd is sinds je hem uitgecheckt hebt, dan krijg je een conflict. Als dat conflict automatisch te resolven is (oftewel, de server kan de wijzigingen mergen en dat gaat goed), dan gebeurt dat. Als dat niet zo is, dan krijgt de gebruiker een foutmelding voor zijn neus, en een file met de conflicten erin. Het is dan aan de gebruiker om te zorgen dat de conflicten opgelost worden, en daarna wordt de file pas ingecheckt.

Dit is dus bij CVS, maar het werkt als een tiet dus ik neem aan dat dat bij SVN precies hetzelfde werkt.

[Sendy]

Helox-in-a-box schreef op 16 augustus 2004 @ 13:24:
...

Als de client klaar is met z'n code, commit hij de code, de verandering wordt dan dus in de repos gezet. Apache moet dan gelijk de nieuwste versie pakken (of vanuit de repos, of repos moet em automatisch exporteren).

...

Ik zoek dus "iets" om een stap over te slaan, namelijk de stap tussen als de client commit en dat apache de nieuwste versie serveert. Normaal gesproken dien je het project te updaten(indien checkout) of de exporteren(geen .svn dirs) op de webserver en dan is de nieuwste versie pas online.

...

Mij is dit niet zo duidelijk. Welke apache moet nu de nieuwste versie serveren? Je kan gewoon met je browser naar de subversion (met HTTP, niet met DAV) en dan zie je de nieuwste versie. Of bedoel je dat niet?

[Helox-in-a-box]

Sendy schreef op 18 augustus 2004 @ 00:11:
[...]
Mij is dit niet zo duidelijk. Welke apache moet nu de nieuwste versie serveren? Je kan gewoon met je browser naar de subversion (met HTTP, niet met DAV) en dan zie je de nieuwste versie. Of bedoel je dat niet?

ja dat bedoel ik, gewoon met de http naar de subversion repository, maar dat kan normaal gesproken niet omdattet SVN een berkeleyDB gebruikt als opslag.

committen gaat idd gewoon goed met 2 users, er verschijnt dan een conflict en moeje ze mergen.

Creepy schreef op 17 augustus 2004 @ 21:19:
[...]

SVN ondersteunt hooks scripts. Hiermee kan je dus een bepaalde actie laten uitvoeren bij bijv. een commit. Hoe dit werkt staat mooi allemaal uitgelegd in het SVN book dat met nog geen 5 minuten google werk snel te vinden is

Voor de luiaards onder ons: http://svnbook.red-bean.c...02.html#svn-ch-5-sect-2.1

fantastisch, dat lijkt me een mooie schop in de goeie richting het idee is dus dat de file ook wordt geexporteerd naar een lokale path op het moment dat je commit.

[Sendy]

Helox-in-a-box schreef op 19 augustus 2004 @ 11:02:[...]
ja dat bedoel ik, gewoon met de http naar de subversion repository, maar dat kan normaal gesproken niet omdattet SVN een berkeleyDB gebruikt als opslag.

??? Ik kan mijn subversion gewoon via HTTP aanspreken hoor, dan krijg ik de laatste revisie. Dat heeft helemaal niets met berkeleyDB te maken.

Je kan zelfs met svn properties aangeven dat bepaalde pagina's een zeker mime-type moeten krijgen; zo kan je bijvoorbeeld je homepage uit svn serveren, zonder checkout te doen. Mij lijkt dit simpeler dan zelf code schrijven.

[Creepy]

Sendy schreef op 19 augustus 2004 @ 20:45:
[...]

??? Ik kan mijn subversion gewoon via HTTP aanspreken hoor, dan krijg ik de laatste revisie. Dat heeft helemaal niets met berkeleyDB te maken.

Lees nog eens goed de documentatie van SVN

Je kan zelfs met svn properties aangeven dat bepaalde pagina's een zeker mime-type moeten krijgen; zo kan je bijvoorbeeld je homepage uit svn serveren, zonder checkout te doen. Mij lijkt dit simpeler dan zelf code schrijven.

Maar i.p.v. dat de pages rechstreeks gebruikt worden, worden ze wel degelijk uit de SVN database gegenereerd (aangezien echt niet complete files opgeslagen worden, maar alleen de wijzigingen in die files). Dus het opslag formaat (Berkley DB in dit geval) van SVN geeft wel degelijk extra overhead.

Daarnaast lijkt het me niet wenselijk dat iedereen zomaar bij je SVN repository kan komen...

[ Voor 6% gewijzigd door Creepy op 20-08-2004 08:18 ]

[Sendy]

Maar wat jij wenselijk vindt is niet wat ik wenselijk vind, en waarschijnlijk ook niet wat de TS wenselijk vindt. Je kan die toegang natuurlijk beperken (en dat op precies dezelfde manier als dat je commit rechten beperkt!)

En wat heeft de 'overhead' van Berkley DB ermee te maken? Lul-drumstel?

[igmar]

Creepy schreef op 20 augustus 2004 @ 08:18:
Lees nog eens goed de documentatie van SVN

Wat wil je daarmee zeggen ? SVN werkt met een mod-dav koppeling, of rechtstreeks via een svn server. Bij de eerste variant kun je met een browser de repository benaderen.

Maar i.p.v. dat de pages rechstreeks gebruikt worden, worden ze wel degelijk uit de SVN database gegenereerd (aangezien echt niet complete files opgeslagen worden, maar alleen de wijzigingen in die files). Dus het opslag formaat (Berkley DB in dit geval) van SVN geeft wel degelijk extra overhead.

Sja, wat geeft geen overhead tegenwoordig. Met hooks is dit probleem oplosbaar.

Daarnaast lijkt het me niet wenselijk dat iedereen zomaar bij je SVN repository kan komen...

Daarvoor heeft men authorisatie uitgevonden.

[Creepy]

Sendy schreef op 20 augustus 2004 @ 10:53:
En wat heeft de 'overhead' van Berkley DB ermee te maken? Lul-drumstel?

Stel dat je een druk bezocht website hebt, dan lijkt me de extra overhead van Berkey DB en het genereren van de laatste versie van de html bestand me niet wenselijk.

igmar schreef op 20 augustus 2004 @ 11:28:
[...]
Wat wil je daarmee zeggen ? SVN werkt met een mod-dav koppeling, of rechtstreeks via een svn server. Bij de eerste variant kun je met een browser de repository benaderen.

Ik wilde er mee zeggen dat je dan niet rechtsteeks de file ophaalt, maar dat dat via de opslag methode van SVN verloopt (berkey db) i.p.v. rechtsteeks via het filesysteem van de server, dus het wel enigzins IETS met Berkley DB te maken heeft

[ Voor 45% gewijzigd door Creepy op 20-08-2004 14:57 ]

[igmar]

Creepy schreef op 20 augustus 2004 @ 14:55:
Ik wilde er mee zeggen dat je dan niet rechtsteeks de file ophaalt, maar dat dat via de opslag methode van SVN verloopt (berkey db) i.p.v. rechtsteeks via het filesysteem van de server, dus het wel enigzins IETS met Berkley DB te maken heeft

Dat is een logisch gevolg van het feit dat het een versiebeheer systeem is, maar dat is met CVS net zo. Het is ook wel wenselijk denk ik, een bdb file leest niet zo makkelijk

[Creepy]

igmar schreef op 20 augustus 2004 @ 15:42:
[...]
Dat is een logisch gevolg van het feit dat het een versiebeheer systeem is, maar dat is met CVS net zo. Het is ook wel wenselijk denk ik, een bdb file leest niet zo makkelijk

Ik denk dat we elkaar verkeerd begrijpen, of dat ik de T.S verkeerd begrijp.

Voor zover ik het begrijp wil de T.S. na een import/commit de laatste versie van de file beschikbaar stellen via apache voor gebruik in een website (en niet de devvers). Mij lijkt het dan het beste om dat met een hook script te doen die de laatste versie van de betreffende file ophaalt en ergens in een directory neerzet waar de webserver erbij kan i.p.v. een world readable SVN/DAV repository waarbij dus ook iedereen alle versies, al het commentaar e.d. kan lezen.

[igmar]

Creepy schreef op 20 augustus 2004 @ 15:47:
Ik denk dat we elkaar verkeerd begrijpen, of dat ik de T.S verkeerd begrijp.

Voor zover ik het begrijp wil de T.S. na een import/commit de laatste versie van de file beschikbaar stellen via apache voor gebruik in een website (en niet de devvers). Mij lijkt het dan het beste om dat met een hook script te doen die de laatste versie van de betreffende file ophaalt en ergens in een directory neerzet waar de webserver erbij kan i.p.v. een world readable SVN/DAV repository waarbij dus ook iedereen alle versies, al het commentaar e.d. kan lezen.

Echt netjes kan dat niet afaik. Je zou met een crontab kunnen werken, of vanuit de repository een script laten starten. Ik draai gewoon eens per dag een cvs update