[plug] Source control for webapplications

[Onno Benschop]

rod wrote:

>in situations like that I would have 2 little scripts (pull,push)
>that "do the right thing" at pulling the latest data/code down and
>pusing it back up again.
>  
>
No, CVS does this already, it's called checking out and checking in, no 
magic scripts required.

>everyone has to have the discipline to 'pull' before doing work, then
>'push' when happy with the work... and any manner of 'nasties' can be
>hidden in the pull and push scripts ;P
>  
>
No, CVS manages this and will also allow you to merge changes.

>I do have some suggestions tho....
>
>1) I would not have the live database as the 'master schema' ... I would
>have some scripts that created the correct schema, and these would live
>in the revision control system - this means you would not be using the
>live database at all on devel machines, which would be correct imho.
>  
>
Well, a live database and a test database are two different animals. 
Likely a live database will require an actually connection to it, but 
checking out a mysqldump of the SQL to make the test database is trivial.

You could also use mysqldump to get the schema from the dev box, update 
that into the local checked out version, then check that back into the 
repository, so the schema is also tracked by revision control.

>2) do use Arch or subversion or CVS or any revision control system ...
>having multiple people work directly on live code is a disaster waiting
>to happen... I cant imagine working without the safety of revision
>control.. it makes me shudder ;)
>  
>
No, that is why revision control exists.

>3) make the live site a 'checked out' or 'pull'ed version... this way
>you can decide when the new code goes live by only updating it when the
>developers have fully tested their new code. if you have (as suggested)
>moved all the database creation/population to scripts in cvs (where they
>belong!) you then deploy the new site on a test/devel machine easily.
>  
>
Yes.


At this point you should likely know where I'm coming from. I've not 
seen the Arch seminar, nor have I used any other revision control system 
other than tar and CVS. My change from tar to CVS two years ago has made 
it possible to actually finish an application and bring it to market, 
something that I cannot see ever having happened using the tar revision 
control method (eg. like cp -r)

I write software in PHP/MySQL and my code-base is now an application 
that consists of 14000 lines of PHP.

So, while it isn't the worlds largest application, it does work really 
well for what I need.

I use LinCVS as a GUI to CVS, which also runs cross-platform on Linux 
and Windows, so the developer need never actually get their hands dirty 
inside CVS.

Also, there are better revision control systems around beyond CVS and 
while I'm interested in those, I've not yet found a better GUI than 
LinCVS, so I stay with CVS for all its faults.


Cheers,

-- 
Onno Benschop

Connected via Optus B3 at S34°32'27" - E146°24'35" (Leeton, NSW)
--
()/)/)()        ..ASCII for Onno..
|>>?            ..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon
ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219 8888   -   onno at itmaze.com.au