The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Subversion: Going from Source to Production?
Seguer
of the VoidSydney, AustraliaRegistered User regular
of the VoidSydney, AustraliaRegistered User regular
Hi guys,
I've just started using Subversion for a university project and I've just coded a little test project to test for mysql connectivity. However attempting to run the PHP file only shows the source code! What do I have to do to get it to treat as a PHP file and let php execute it?
I've just started using Subversion for a university project and I've just coded a little test project to test for mysql connectivity. However attempting to run the PHP file only shows the source code! What do I have to do to get it to treat as a PHP file and let php execute it?
Seguer on
0
Posts
(Also, I wasn't trying to do a live deployment as such, I'm just trying to test some stuff)
These are one-line commands on the Web server, so automating it is really a matter of just running that command (put it in a script if you want). If you want to do it periodically (e.g., nightly) you can set it up as a cron job. If you want to set it up so every commit goes live immediately (although that's really a weird concept), it is possible to set up svn commit hooks that execute every time a commit is made.
How would I go about creating (for example) a PHP script that would be able to perform that command (svn export to production directory)?
make sure your mappings are correct, and that your server is parsing php at all. can you do phpinfo()?
1. It is a regular practice to serve SVN repositories via HTTP using Apache. As such, if you're developing a website with svn, it's possible to 'preview' the current copy in the repository by simply pointing a browser at the right page. This works - kinda. However, certain advanced server features (running PHP, for example, or serving up pages with SSI) don't necessarily work right because these often require additional tweaks in the Apache config files to activate them on the content in the svn repository.
The problem with doing this, of course, is that you don't want to mess up your regular SVN access to the repository over HTTP. So, what I've done in the past is create two aliases to the repository in the Apache config files: /svn/ (for normal repository checkin/checkout) and /svn4www/ where all the nifty extensions are enabled.
With PHP scripts specifically, I believe you should be able to run PHP scripts directly out of the repository, although I'm not 100% sure. You may need to tweak the Apache config to get this to work, and some browsers (IE specifically) may handle things like incorrect Content-types better (or, if you like more liberally) than Firefox. You may have to add some directives to the apache config file that governs your svn repository like shown here.
2. If you want to keep the repository separate from the production directory and then do an update or export, you can do what I said above and periodically run an export. How you kick this off is your business. You can set up a commit hook, as described here. If you want to kick it off from a PHP script, then effectively you want to exec a process on the server, probably with this PHP module. The command is probably something like:
svn export http://path/to/my/repos /my/production/directory
or
svn export --username myuname --password mypwd http://path/to/my/repos /my/production/directory
if the repository is password-protected for export.
flatlinegraphics: I know about PHP and how it works
Admittedly, I had assumed that you could access the files as you would normally - and they would run as normal. How else would you know if the code you just programmed would compiled and run properly? :S
I don't think you understand what version control is supposed to achieve.
Version control, ala Subversion, CVS, Git, is a repository of all the edits ever made to software. It lets multiple people work on files at once, and merge those edits together. It is not a way to deploy anything. Think of it like locking away your code in a safe. When you want to deploy it, you make a duplicate of the latest thing in the safe.
You're supposed to have tested the code in some way before it hits the repository, or you can screw things up for other people. Of course, no-one is perfect, which is why you typically have an "unstable" latest version, and tag a version which was stable and feature-complete.
Frylock's system he described in 1., while no doubt effective, is really not what I would suggest you do. You should always be running live code from an exported version, not out of SVN. That SVN lets you do this, it doesn't mean you should. As we just said, SVN is the unstable area, but not a place to begin testing at all. You should use 2., but you should have tested your code well before it hit SVN. You should have your own server/folder you can use to export to and test privately, before you commit to SVN.
The quick/dirty way is to just have a folder called "private/[username]" or something that they can export to.
I develop CGI/Perl scripts all day, and just test them in my home folder on the server before I commit to CVS. Not very secure, but I have nothing to hide from my users. You might.
never know.:P
when something goes pear shaped, go for the basic questions. had a new server set up, and had short tags off in the ini and it drove me nuts for hours as every single script on the server failed.
and i'll be back on in a a day or two asking you about setting up phpmyadmin. thats next on the server list...
i'm going to have to look through that. we;re on a WIMP, but it should be close (hopefully).
and it was mostly inherited code, and as you might guess from the username, i'm a designer that got strapped into being a web dev through necessity rather than training.