Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
Hello John, >> We have a similar web development scenario and the difference to normal >> development is that it is much easier to install a compiler on each >> developers box than a complete webserver. Webserver installations tend >> to be done centrally. > > Have a test web server, with it's own sandbox, and only update the > production site when you are completed. This is the only way to sanely > handle large updates, since you frequently cannot incrementally change > the site. thank you for your comprehensive description. Unfortunately my problem is somewhat different. We do not want to update the production machine with cvs, for that we have a cms solution. The php developer only work on a test webserver. So the usual way to do updates is like: 1. edit a page 2. reload page in browser to check if your change solves the problem or your addition is ok 3. fix some bugs 4. reload/check again Due to the nature of web development you repeat step 3 and 4 a couple of times before the php and especially the html code is ok. If you have to commit every time to iterate step 3 and 4 there are a lot of version in the repository which are only intermediate steps and are not working. So if you ever want to go back from the current version to the previous one, you must go back several revisions without exacly knowing which one is the next working one (maybe it is possible to use tags to mark the working revisions but in my opinion this is to difficult, isn't it? And even with tagging you still have a lot of unnecessary revisions in the repository). So my idea is to only commit correct changes to cvs. But the developer must still be able to check his changes on a webserver before commiting. The setup of the test webserver is complex and change often. So it is not reasonable to install such a webserver on each developer's box. So I have the idea of sandboxes on a network share, one sandbox for each developer, but all sandboxes on a share on the test webserver. But this setup is not supported and I need a robust solution. Hopefully I described my problem clearer now. So what to do in this situation? Mabe I make things to complicate and there is a much easier solution. Bye, Torsten > We have been doing this for ages and it works really well. The key steps > are these: > > 1) Install the test web server on the CVSNT repository machine itself > 2) Checkout a sandbox for the web server (don't point the web server > directly at the repository files!) 3) Set up a replication scheme to keep > the web server synced to the repository > > Until recently, we used CVSNTUPD.exe (a little utility I wrote) to keep > the sandboxes in sync (with a delay of ~ 1 minute). Now, with the > massively cool postcommit option (Thanks Tony!), I have a little perl > script which correctly updates the sandbox immediately. The script is > not really ready for public distribution (it's very ugly), but it works > fine for us. > > HTH > > John -- o __ innovativ partner I l_) office at ip-team.de l www.ip-team.de 02 31 / 14 20 57