[plug] Source control for webapplications
onno at itmaze.com.au
Wed Mar 16 15:00:24 WST 2005
>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.
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
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.
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
More information about the plug