Edmund Hertle wrote:
2009/1/19 Nathan Rixham <nrixham@xxxxxxxxx>
well the idea of svn is that should you find a problem you either rollback
the file(s) to the good version (not rollback the whole site) or you commit
updated files with the fix, then redeploy. No need to branch or such like.
Well, yes, of course there also will be bugs in "good" versions but I think
it should more be like: "Well, there is a bug.. maybe switch 2 or 3
revisions back and than we see" and not like "Oh, a bug. maybe 100 - 150
revisions back, which were all created yesterday"
ahh but the whole code base has gone up by say 100 revisions so full
site version number is 800, however the current version of faulty file
is 589 and the previous version of that file is 453, you only revert
that particular file.. not the whole code base, then recommit making the
full site version 801, without loosing any other work :)
By locally created and tested scripts you will of course not have those
probs because you're not comitting everything. But locally developing brings
some kind of care-taking like making sure you use everywhere the same
version (php, mysql, webserver), installed the same extensions, have the
same php.ini, than there the whole database... and php is not my main work
;)
but committing to svn is not updating the site, it's just storing
changes so you can rollback "version control" you don't release every
version, just the stable one.. so your live code base never changes
unless you specifically and manually do it (or make a script to do it
that you control)
I thought with using maybe another branch all those 100-150 revisions are
stored away and the main branch is than again more like, well going back 1-2
revisions is equal to 1-2 days of work.
see above, you don't have to roll back a whole sites version, just the
specific file in question, the rest of the code base stays the same.. or
better yet diff the current faulty version of the file with previous
versions of it, find what changed then fix and commit. either aproach
works - important thing is each file is independent so you don't loose
changes to all files unless you rollback the whole site (think I've made
that clear now :p)
maybe more importantly.. you shouldn't really be getting to production live
with these errors (you always will at some point) - perhaps you want to look
at unit testing, and even continuous integration/building while you're
there.
all those talking was only about the developing server. Unit testing I heard
of but not really understand how to use and what excatly unit testing does.
perhaps i wasn't clear, svn is a repository system, version control, you
don't run a site off it, you use it to keep track fo your files and
changes to them, controlling the versions. when you're happy you can
just ftp away like normal, or as i mentioned scp the files straight from
server to server.
ps: pdt-eclipse is great, you can integrate it right in with svn for handy
diff's, commits, updates etc (and svn in with bugzilla, mylyn loads more..)
yes, I'm already using pdt-eclipse with subclipse. What's mylyn about?
(again heard of ;) )
in short, task manager for eclipse which integrates with bug tracking
software, very nice features such as remembering what code you where
using for each task, so you can switch tasks and the files in view will
swap dependant on tasks, probably best checking the site and demo videos
around the net for more info.
And btw: what is "scp"?
scp - secure copy, command line tool for securely copying files from
server to server [http://en.wikipedia.org/wiki/Secure_copy]
in short:
scp -r /var/sitename/www/* user@xxxxxxxxxxxx/var/www/
will copy all the files in /var/sitename/www over to folder /var/www on
server "sitename.com"; but in a few seconds as it uses server to server
transport AND is much faster than ftp.. so instead of ftping a site
which can take ages, it just takes seconds to rollout a whole new site,
or rollback to a previous version :)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
