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 sales@march-hare.com.
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