[Linux] Website ontwikkeling met CVS

[Kluus]

Ik heb op mijn webserver (Gentoo linux) een CVS server opgezet voor gebruik met een project voor school (zijn bezig met het maken van een eCommerce site).
Nu hebben we bij het maken van de aanvankelijke website gewoon via ftp gewerkt, en zijn tot de conclusie gekomen dat CVS toch wel makkelijk zou zijn.

Dan nu het probleem, de repository die ik gemaakt heb voor het project is /home/cvs/{naam website}, terwijl de directory van de site zelf /home/httpd/{naam website} is. Het liefst laat ik deze indeling zoals ie is.
Zijn er misschien ideeen hoe ik dit het beste kan koppelen (ik heb zelf bedacht dit via symbolic links te doen) of dat ik misschien toch beter een gemeenschappelijke cvs/httpd directory kan maken?
Verder zit ik een beetje met de users, hoe zorg ik dat de bestanden die via cvs geupload worden de groep apache hebben?

Alvast bedankt!

[Jelmer]

Is de /home/cvs een checkout van de repository of is dat repository zelf? In het laatste geval zul je toch echt handmatig een checkout/update/export moeten doen in /home/httpd

[Kluus]

Jelmer schreef op dinsdag 23 november 2004 @ 18:37:
Is de /home/cvs een checkout van de repository of is dat repository zelf? In het laatste geval zul je toch echt handmatig een checkout/update/export moeten doen in /home/httpd

De situatie is zo:

/home/cvs is inderdaad de repository zelf, en /home/httpd is de directory waar de eigenlijke website staat, deze wordt gebruikt voor het reviewen/testen van de website als iemand een verandering heeft aangebracht.

Nou is het de bedoeling dat projectleden die aan de website gaan werken een checkout maken op hun eigen machine, en wanneer ze dit terug zetten kunnen ze het resultaat zien op de site zelf (dus van de bestanden in /home/httpd).

Zou ik zon checkout/update/export automatisch naar /home/httpd kunnen laten doen wanneer er iets in de repository gewijzigt wordt?

(We werkten eerst gewoon via ftp op /home/httpd maar dit leidde op den duur tot frustraties omdat er dingen overschreven werden die mensen net hadden gemaakt enzo. Dit hopen we dus tegen te gaan met behulp van CVS, maar ik ben een CVS-ubernoob, en aangezien ik de server beheer wordt van mij verwacht dat ik ook wel eventjes CVS regel, vandaar )

[ Voor 4% gewijzigd door Kluus op 23-11-2004 18:47 ]

[Rukapul]

normaal kun je bij een checkin op de server een script uitvoeren, bv om een email te sturen naar alle projectleden. In dat script kun je natuurlijk ook een cvs update -d uit laten voeren voor de checkout in de httpd directory.

Ik zou nooit direct naar een repository linken. Dat werkt fouten in de hand, bv een domme user die in /home/httpd wat doet en dat dan je halve repository aan gort is.

edit: waarom wil je eigenlijk dit bij elke update? ik neem aan dat iedereen ook nog een lokale werkkopie heeft? In dat geval hoef je toch alleen handmatig een update te doen om een nieuwe 'release' algemeen te delen...?

[ Voor 23% gewijzigd door Rukapul op 23-11-2004 18:56 ]

[tomato]

TjaBske schreef op dinsdag 23 november 2004 @ 18:46:
Zou ik zon checkout/update/export automatisch naar /home/httpd kunnen laten doen wanneer er iets in de repository gewijzigt wordt?

Ik zou het je niet aanraden, maar in Subversion termen doe je dit met hook-scripts. Ongetwijfeld kun je iets dergelijks in CVS.

[Sendy]

Dat kan wel inderdaad, maar ik ken geen direct bruikbare tools om dat met CVS te doen. Zoek eens op de zoekterm "hooks" en cvs.

Met subversion (de sinds-lang verwachte opvolger van cvs) kan dit heel makkelijk: een repository is direct via HTTP (subset van DAV) te benaderen. Je moet dan wel in subversion de mime-types aangeven, want een source code management systeem kent geen file-types.

[Verwijderd]

tomato schreef op dinsdag 23 november 2004 @ 18:54:
Ongetwijfeld kun je iets dergelijks in CVS.

In je CVSROOT kun je scripts neerzetten die gerunt worden tijdens commit. Voor GStreamer hebben we de website ook in CVS, en wordt tijdens commit automatisch de website geupdate (middels een ssh naar de website, checkout van de nieuwe CVS, compile XMl -> xHTML, exit). Is niet moeilijk, en is overal documentatie voor te vinden.

[Kluus]

Rukapul schreef op dinsdag 23 november 2004 @ 18:54:
normaal kun je bij een checkin op de server een script uitvoeren, bv om een email te sturen naar alle projectleden. In dat script kun je natuurlijk ook een cvs update -d uit laten voeren voor de checkout in de httpd directory.

Ik zou nooit direct naar een repository linken. Dat werkt fouten in de hand, bv een domme user die in /home/httpd wat doet en dat dan je halve repository aan gort is.

edit: waarom wil je eigenlijk dit bij elke update? ik neem aan dat iedereen ook nog een lokale werkkopie heeft? In dat geval hoef je toch alleen handmatig een update te doen om een nieuwe 'release' algemeen te delen...?

Op dit moment is het zo dat deze server puur als ontwikkelserver wordt gebruikt, en mensen bekijken hun wijzigingen rechtstreeks vanaf de server wanneer deze gedaan zijn. (Zo hoeft ook niet iedereen thuis een php server op te zetten enzo om hun code te testen).

[Kluus]

Verwijderd schreef op dinsdag 23 november 2004 @ 19:11:
[...]


In je CVSROOT kun je scripts neerzetten die gerunt worden tijdens commit. Voor GStreamer hebben we de website ook in CVS, en wordt tijdens commit automatisch de website geupdate (middels een ssh naar de website, checkout van de nieuwe CVS, compile XMl -> xHTML, exit). Is niet moeilijk, en is overal documentatie voor te vinden.

Thanks, ik ga het uitzoeken .

[Wilke]

TjaBske schreef op dinsdag 23 november 2004 @ 19:12:
Op dit moment is het zo dat deze server puur als ontwikkelserver wordt gebruikt, en mensen bekijken hun wijzigingen rechtstreeks vanaf de server wanneer deze gedaan zijn. (Zo hoeft ook niet iedereen thuis een php server op te zetten enzo om hun code te testen).

Wat is dan nog het nut van CVS, zou ik bijna willen vragen.

Als je op deze manier ontwikkelt moet je continu inchecken op CVS. Je krijgt daardoor een bijzonder chaotische revision history.

Maar goed, beter een chaotische history dan helemaal geen history, zal waarschijnlijk het idee zijn

[Kluus]

Wilke schreef op dinsdag 23 november 2004 @ 19:19:
[...]


Wat is dan nog het nut van CVS, zou ik bijna willen vragen.

Als je op deze manier ontwikkelt moet je continu inchecken op CVS. Je krijgt daardoor een bijzonder chaotische revision history.

Maar goed, beter een chaotische history dan helemaal geen history, zal waarschijnlijk het idee zijn

Eigenlijk is het enige wat we nodig hebben de mogenlijkheid van het detecteren van veranderingen of (misschien wel nog beter) het locken van bestanden. Hiervoor zijn we aan CVS begonnen. Als er echter een ander/beter alternatief is die alleen dit doet, hoor ik die ook graag .

[Spider.007]

TjaBske schreef op dinsdag 23 november 2004 @ 19:46:
[...]


Eigenlijk is het enige wat we nodig hebben de mogenlijkheid van het detecteren van veranderingen of (misschien wel nog beter) het locken van bestanden. Hiervoor zijn we aan CVS begonnen. Als er echter een ander/beter alternatief is die alleen dit doet, hoor ik die ook graag .

Als ik jou was zou ik het al eerder genoemde subversion eens bekijken; dat biedt via een standaard filesystem view altijd de laatste versie van een bestand aan; en is via speciale tools te benaderen om versiebeheer specifieke opdrachten te geven

[chris]

Wilke schreef op dinsdag 23 november 2004 @ 19:19:
Als je op deze manier ontwikkelt moet je continu inchecken op CVS. Je krijgt daardoor een bijzonder chaotische revision history.

Je kan die users toch een homedir geven en ze dus laten testen op http://bak/~username/project

en zorgen dat ze vervolgens moeten committen?

[Verwijderd]

Ik heb voor websites met cvs ooit dit script geschreven: http://compukid.no-ip.org/dev/scripts/cvspublish

[Verwijderd]

Spider.007 schreef op dinsdag 23 november 2004 @ 20:38:
Als ik jou was zou ik het al eerder genoemde subversion eens bekijken; dat biedt via een standaard filesystem view altijd de laatste versie van een bestand aan; en is via speciale tools te benaderen om versiebeheer specifieke opdrachten te geven

Dude, svn en cvs hebben exact hetzelfde manco wat dat betreft. Je moet simpelweg lokaal een webserver draaien om changes te checken voordat je ze submit.

[Verwijderd]

Voor het locken van bestanden kan je miscchien beter RCS gebruiken ipv van CVS, het is een stuk simpeler en veel minder krachtig maar misschien wil je dat juist wel.

[chris]

Verwijderd schreef op woensdag 24 november 2004 @ 20:35:
[...]
Je moet simpelweg lokaal een webserver draaien om changes te checken voordat je ze submit.

Nee hoor. Ze zijn beide prima commandline te gebruiken op je lokale bak. Oftwel, inloggen met ssh en die tools gebruiken. Als je remote wil devven en vervolgens de veranderingen wil committen zou je het kunnen oplossen met een webserver, maar je kan ook een subversion-server draaien (die ook over ssh kan werken).