Re: [PHP] Re: How to use SVN + PHP
Another tidbit... I am fairly new to SVN or any Version Control System. Whether its CVS, SVN, or GIT a VCS is essential even for solo projects. My setup is as follows, [and it seems to work pretty well]: 1. svn repo lives on dev server. 2. everything is in the trunk. I haven't touched branches and / or tags yet. 3. users connect to repo via http using htaccess users passwords 4. post-commit script runs svn update after anyone commits to the repo. This runs svn update on the dev server. 5. after the boss approves the dev server work, the production server runs svn update too. The production has a checked out working copy of the source repo. I chose this method because our clients also FTP some files to the server, and using svn export would be too complicated. The production server connects to the repo via an ssh user using an ssh key and restricted to this command svnserve -t -r /var/svnrepo. The svn up on the production server is a manual process. I login via ssh, cd to the webroot, and type svn up. Our dev team is using eclipse-pdt and subclipse plugin which integrates eclipse and subversion. Subversion or any VCS is essential. After 15 years of using FTP/SFTP/SCP, SVN has replaced it for all my web projects. On Tue, Jan 20, 2009 at 3:31 AM, Ross McKay ro...@zeta.org.au wrote: On Mon, 19 Jan 2009 22:32:49 +0100, Edmund Hertle wrote: I'm thinking about implementing Subversion to an existing php project for obvious reasons. Yay! What Nathan said, plus a couple of comments from me... [...] My ideas about using SVN are these: - Repository is managing trunk, branch and tag - Live-server works as client of the rep, getting the latest tag - Develop-server uses mainly latest trunk and of course branches as needed Personally, I'd just work in the trunk. Even with multiple developers, stick to working in the trunk. On release, copy the trunk to a tag to preserve its state. Branches are great for long-running diversions from the trunk, e.g. when creating a whole new release with new features and potentially different architecture, copy the trunk to a branch so that maintenance work can continue on the branch, and perform new work on the trunk. Of course, you can do that the other way around, new work on the branch and maintenance on the trunk, but that means merging the branch into the trunk at the end and potentially creating a new branch for maintenance... i.e. the same result as the other method, but with more effort. Putting it another way: working in branches is good for maintaining separate codebases concurrently, either because of feature differences or platform differences (e.g. a Linux branch and a Windows branch). NB: in Subversion, there really isn't proper support for either branches or tags; we just emulate it by copying a folder to another folder. A tag is then just a copied folder that is never altered again, and a branch is a copied folder that is later modified. Convention has us calling these things tags and branches, and calling the original folder the trunk. For simple websites, I tend to drop the trunk/tag/branch model entirely and just work in the trunk. Some things just don't warrant the extra work :) but they still benefit from revision control. [...] Is it possible to configure one client (here develop-server) to automatically updating from rep if something is committed? IMHO, that would be a Bad Thing(R) because it means only committing to the repository when it works. Alternatively, it could mean releasing untested changes to production, an even more Bad Thing(R). Better is to commit early, commit often and thus get deep undo through Subversion's history of changes. Once you've tested your changes and are happy that everything is working, and committed them all to the trunk, copy the trunk to a tag and put that on the server. -- Ross McKay, Toronto, NSW Australia Let the laddie play wi the knife - he'll learn - The Wee Book of Calvin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- life your own way. http://www.talkderby2me.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: How to use SVN + PHP
derby wrote: Our dev team is using eclipse-pdt and subclipse plugin which integrates eclipse and subversion. Subversion or any VCS is essential. After 15 years of using FTP/SFTP/SCP, SVN has replaced it for all my web projects. you can get the RSE plugin for eclipse-pdt as well; I'd really recommend it, in short it's remote system explorer and allows you to connect to any server by almost any protocol, so you can ssh, ftp, scp, sftp, webdav whatever from inside eclipse. further there's the communications plugin which let's you msn, xmpp, aim etc from inside eclipse too finally make sure you have the zend eclipse debugger plugin for eclipse installed as well, let's you run php right in eclipse and debug etc, doesn't come with pdt-1 if i remember correctly -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: How to use SVN + PHP
On Mon, 19 Jan 2009 22:32:49 +0100, Edmund Hertle wrote: I'm thinking about implementing Subversion to an existing php project for obvious reasons. Yay! What Nathan said, plus a couple of comments from me... [...] My ideas about using SVN are these: - Repository is managing trunk, branch and tag - Live-server works as client of the rep, getting the latest tag - Develop-server uses mainly latest trunk and of course branches as needed Personally, I'd just work in the trunk. Even with multiple developers, stick to working in the trunk. On release, copy the trunk to a tag to preserve its state. Branches are great for long-running diversions from the trunk, e.g. when creating a whole new release with new features and potentially different architecture, copy the trunk to a branch so that maintenance work can continue on the branch, and perform new work on the trunk. Of course, you can do that the other way around, new work on the branch and maintenance on the trunk, but that means merging the branch into the trunk at the end and potentially creating a new branch for maintenance... i.e. the same result as the other method, but with more effort. Putting it another way: working in branches is good for maintaining separate codebases concurrently, either because of feature differences or platform differences (e.g. a Linux branch and a Windows branch). NB: in Subversion, there really isn't proper support for either branches or tags; we just emulate it by copying a folder to another folder. A tag is then just a copied folder that is never altered again, and a branch is a copied folder that is later modified. Convention has us calling these things tags and branches, and calling the original folder the trunk. For simple websites, I tend to drop the trunk/tag/branch model entirely and just work in the trunk. Some things just don't warrant the extra work :) but they still benefit from revision control. [...] Is it possible to configure one client (here develop-server) to automatically updating from rep if something is committed? IMHO, that would be a Bad Thing® because it means only committing to the repository when it works. Alternatively, it could mean releasing untested changes to production, an even more Bad Thing®. Better is to commit early, commit often and thus get deep undo through Subversion's history of changes. Once you've tested your changes and are happy that everything is working, and committed them all to the trunk, copy the trunk to a tag and put that on the server. -- Ross McKay, Toronto, NSW Australia Let the laddie play wi the knife - he'll learn - The Wee Book of Calvin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: How to use SVN + PHP
Edmund Hertle wrote: Hey, I'm thinking about implementing Subversion to an existing php project for obvious reasons. But I have some trouble when thinking about the usage. there are lots of ways of using svn and I'm sure you'll get different opinions.. personally I always create a script to deploy to live.. just a little bash script that prompts me for the version number to use, then it scp's the files over in a second. as for the development process; normally I develop and test locally, then when happy scp from svn to staging site, then when clients happy scp to live site (with scripts, and version tagging in svn). Next problem: While writing new code there are many small bugs like used an array instead of an string or other way round forgotten parameters and so on. Usually there are quite some file transfers until some piece of code works quite well. But with the method above all these versions would end up being in the rep and kind of polluting it. To solve this I thought about just creating a branch with every work cycle (so after updating until committing a working version) and than while committing also merging it back with current trunk/branch... 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. 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. 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..) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: How to use SVN + PHP
2009/1/19 Nathan Rixham nrix...@gmail.com 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 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 ;) 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. 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. 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 ;) ) And btw: what is scp? -eddy
[PHP] Re: How to use SVN + PHP
Edmund Hertle wrote: 2009/1/19 Nathan Rixham nrix...@gmail.com 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/* u...@sitename.com/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
[PHP] Re: How to use SVN + PHP
sorry i commented in all the wrong places :| Edmund Hertle wrote: 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 ;) you don't have to locally develop, you can develop however you want :) svn is just version controlling all your files to make it easier to team work and to rollback code. you then tag good versions of the code in svn so you have a permanent easy to access good version of the site (which you then copy and do what you want with, download, ftp whatever) keeps you safe :) it's kind of like taking a zip/backing up the site everytime it's error free - but on steriods. 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. unit testing is where you write tests for each small section of code, say each function or object/method - you write a test so you know the code works, then when you change anything in the code you can run the test again and if it fails.. well you have a bug - way more too it so see: http://en.wikipedia.org/wiki/Unit_testing I'd recommend: http://www.phpunit.de/ however simply writing tests for your code yourself is a good start - something somewhere on the internet says: whenever you feel like writing a print_r or var_dump or echo'ing a variable, don't - write a test instead - not always practical but still good thinking. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: How to use SVN + PHP
2009/1/20 Nathan Rixham nrix...@gmail.com you don't have to locally develop, you can develop however you want :) svn is just version controlling all your files to make it easier to team work and to rollback code. you then tag good versions of the code in svn so you have a permanent easy to access good version of the site (which you then copy and do what you want with, download, ftp whatever) keeps you safe :) Yeah, I think I mix up (web)server and rep some times... But to point out an example: There is a script on the (develop) webserver, the same locally and of course in the rep. So I start working on the local copy and now want to try it. So what should I do? Copying directly to the webserver, testing and than later after some more work commit to the rep? Or other way: Start working on script, commit to rep, than update (develop)webserver, than testing? If way one would work without problems, well I think I would just do it that way, but won't there be some problems when copying files to server, than changing files locally and instead copying again to webserver committing it. So now updating webserver will cause some probs because I think SVN will try to merge both files if possible? But as of my working style the files on the server should not be merged but overwritten with the files of SVN? I hope I explained my prob a bit more... And with SCP: I'm forced to work on a windows server and there was no ftp at all so I was forced to use windows explorer and those (don't know how it's called on english) networkdevice connection which is 10 times more frustrating than using ftp (funnily it works smoother when using linux to connect to...). So I will look into WinSCP and hope it will work.. thanks for advice -eddy
[PHP] Re: How to use SVN + PHP
Edmund Hertle wrote: 2009/1/20 Nathan Rixham nrix...@gmail.com you don't have to locally develop, you can develop however you want :) svn is just version controlling all your files to make it easier to team work and to rollback code. you then tag good versions of the code in svn so you have a permanent easy to access good version of the site (which you then copy and do what you want with, download, ftp whatever) keeps you safe :) Yeah, I think I mix up (web)server and rep some times... But to point out an example: There is a script on the (develop) webserver, the same locally and of course in the rep. So I start working on the local copy and now want to try it. So what should I do? Copying directly to the webserver, testing and than later after some more work commit to the rep? Or other way: Start working on script, commit to rep, than update (develop)webserver, than testing? how you get the script to testing is up to you; as for svn commit frequently and often, the more versions you have in svn the better, every time you add to svn you have a backup. I commit to branch overy time i hit save, i commit to trunk everytime there is no errors. (thats just me though - how you use is up to you, the question is do you see benefit to using source control/svn, if yes, use it however you want) If way one would work without problems, well I think I would just do it that way, but won't there be some problems when copying files to server, than changing files locally and instead copying again to webserver committing it. So now updating webserver will cause some probs because I think SVN will try to merge both files if possible? But as of my working style the files on the server should not be merged but overwritten with the files of SVN? I hope I explained my prob a bit more... a merge is something you do manually, most of the time you just commit (overwrite) and svn will log the lines of code that changed - sometimes when multiple people work on the site you get a conflict, both changed the same lines - this is when you need to manually review and manually merge, SVN will tell you the files conflict and prompt you to merge (still with the option to overwrite, or to update, take the other persons copy) And with SCP: I'm forced to work on a windows server and there was no ftp at all so I was forced to use windows explorer and those (don't know how it's called on english) networkdevice connection which is 10 times more frustrating than using ftp (funnily it works smoother when using linux to connect to...). So I will look into WinSCP and hope it will work.. thanks for advice if server is a windows server maybe forget scp.. may be more trouble than it is worth. but if server is linux and you develop on windows then yes use winscp or tortoise svn, or both :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: How to use SVN + PHP
Edmund Hertle wrote: 2009/1/20 Nathan Rixham nrix...@gmail.com you don't have to locally develop, you can develop however you want :) svn is just version controlling all your files to make it easier to team work and to rollback code. you then tag good versions of the code in svn so you have a permanent easy to access good version of the site (which you then copy and do what you want with, download, ftp whatever) keeps you safe :) Yeah, I think I mix up (web)server and rep some times... But to point out an example: There is a script on the (develop) webserver, the same locally and of course in the rep. So I start working on the local copy and now want to try it. So what should I do? Copying directly to the webserver, testing and than later after some more work commit to the rep? Work on the webserver directly, or set up a test environment on your machine. You could set up a samba share or shared drive on the server, or if it's a *nix based server, use an editor that lets you sftp (which is secure ftp - like ftp but across a secure port, usually ssh). Or other way: Start working on script, commit to rep, than update (develop)webserver, than testing? Test your changes, then commit. When you look at the repo, at least you know most of the functionality works at any point in time. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: How to use SVN + PHP
2009/1/20 Nathan Rixham nrix...@gmail.com a merge is something you do manually, most of the time you just commit (overwrite) and svn will log the lines of code that changed - sometimes when multiple people work on the site you get a conflict, both changed the same lines - this is when you need to manually review and manually merge, SVN will tell you the files conflict and prompt you to merge (still with the option to overwrite, or to update, take the other persons copy) Ok, I think now even I understood... So now the next step is to convince my boss to implement and use svn and that it will not complicate things to much (even less). Thanks to you this part will be easier ;) if server is a windows server maybe forget scp.. may be more trouble than it is worth. but if server is linux and you develop on windows then yes use winscp or tortoise svn, or both :) hm, no, sorry, other way round. I by myself work on both, windows and linux (ubuntu) but server is windows. And convincing my boss to switch to linux or even to apache (using IIS atm) is not possible... already tried ;)But at the next meeting I will bring up SCP... the university network I think is already supporting it, so maybe it won't be to complicated... (server is part of the network... but true, the network mostly uses linux...)
