Incoprorating SVN into my current workflow
Moderator: General Moderators
-
LonelyProgrammer
- Forum Contributor
- Posts: 108
- Joined: Sun Oct 12, 2003 7:10 am
Incoprorating SVN into my current workflow
Hi all,
Currently, this is how I manage my PHP projects.
1) Register a webhost with PHP 5
2) On my Windows XP machine, I do the code
3) Upload to the webhost to test
I don't run a apache/php5 on my own localhost anymore because of file system and other incompatibility between linux and windows xp.
Right now, I am thinking of how to incorporate SVN for a group project...So the workflow looks like
2) Update from SVN
3) do changes
4) upload to live server
5) upload to SVN
Is there a way I can combine step 4 and step 5 together?
Currently, this is how I manage my PHP projects.
1) Register a webhost with PHP 5
2) On my Windows XP machine, I do the code
3) Upload to the webhost to test
I don't run a apache/php5 on my own localhost anymore because of file system and other incompatibility between linux and windows xp.
Right now, I am thinking of how to incorporate SVN for a group project...So the workflow looks like
2) Update from SVN
3) do changes
4) upload to live server
5) upload to SVN
Is there a way I can combine step 4 and step 5 together?
Re: Incoprorating SVN into my current workflow
A good package to run a server on XP without trouble is XAMPP http://www.apachefriends.org/en/xampp.html . it's a standalone app so it doesn't change anything to your system. That way you can update your local code from the repository. Work on the code, test it locally and when happy commit to the repo and live site
-
LonelyProgrammer
- Forum Contributor
- Posts: 108
- Joined: Sun Oct 12, 2003 7:10 am
Re: Incoprorating SVN into my current workflow
That's an alternative, but there were some bad experiences about file system difference and line breaks characters.
And besides, it's useful to have a live test site so that clients can comment on it (well, if you are into XP, that is)
And besides, it's useful to have a live test site so that clients can comment on it (well, if you are into XP, that is)
Re: Incoprorating SVN into my current workflow
Strange, what kind of problems were that then? When I was on win XP I haven't had any trouble with xampp.
Having a live testsite can be useful indeed when you need feedback. I find it convenient and faster to at least develop local though, and then upload a version to show.
As to your question about step 4 and 5: I'm sure it's only 2 commands in the svn program you use (or the command line) to have an export done from the repository to both the test server and your machine. So I'd change it around:
- update from SVN
- work locally, change stuff
- update changes to SVN
- export to live server from SVN
Having a live testsite can be useful indeed when you need feedback. I find it convenient and faster to at least develop local though, and then upload a version to show.
As to your question about step 4 and 5: I'm sure it's only 2 commands in the svn program you use (or the command line) to have an export done from the repository to both the test server and your machine. So I'd change it around:
- update from SVN
- work locally, change stuff
- update changes to SVN
- export to live server from SVN
-
LonelyProgrammer
- Forum Contributor
- Posts: 108
- Joined: Sun Oct 12, 2003 7:10 am
Re: Incoprorating SVN into my current workflow
Hmm I always been using a client, like TortoiseSVN, and the SVN server is not owed by me (I using http://www.assembla.com, actually).
Let me go and check if TortoiseSVN has a export to online folder function
Let me go and check if TortoiseSVN has a export to online folder function
Re: Incoprorating SVN into my current workflow
How about generating the export from SVN after all changes are committed?
I use pdt-eclipse with subclipse to hook into SVN. Eclipse also has a way to export your project to servers, but I still do it manually using websvn, which creates tarballs from your svn repositories.
I use pdt-eclipse with subclipse to hook into SVN. Eclipse also has a way to export your project to servers, but I still do it manually using websvn, which creates tarballs from your svn repositories.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: Incoprorating SVN into my current workflow
Install cygwin to get your UNIX-like environment. You can run PHP, Apache, MySQL and subversion from withing cygwin.
Subversion is a lot more convenient if you have a local dev server (e.g. localhost).
My workflow goes something like:
svn up
<modify and add files etc>
<run all tests>
svn commit
ant package
<make release to production>
You can run svn on the server if you have shell access, but it'd be tedious having to FTP or SCP the files to the server, run your tests and then commit.
Subversion is a lot more convenient if you have a local dev server (e.g. localhost).
My workflow goes something like:
svn up
<modify and add files etc>
<run all tests>
svn commit
ant package
<make release to production>
You can run svn on the server if you have shell access, but it'd be tedious having to FTP or SCP the files to the server, run your tests and then commit.
- andre_c
- Forum Contributor
- Posts: 412
- Joined: Sun Feb 29, 2004 6:49 pm
- Location: Salt Lake City, Utah
Re: Incoprorating SVN into my current workflow
What I would probably do in that situation is write a script that checks out the project from subversion to the live site and call that script using the post-commit subversion hook.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: Incoprorating SVN into my current workflow
Those scare me. That means that as soon as somebody commits broken code it ends up in production and rolling back becomes tricky. I prefer to make very atomic commits (I pretty much commit every single time I change a file) and release into production once I have completed a new feature (many many commits later). Making a release can be as simple has zipping the code, uploading it and unzipping it on the server.andre_c wrote:What I would probably do in that situation is write a script that checks out the project from subversion to the live site and call that script using the post-commit subversion hook.
If you are going to go down the post-commit road you need to make sure you're always working in a branch which is NOT the same branch your production code checks out from, then merge in your new changes once you've completed a feature. Externals can be a problem if you're not using explicit revisions. When you tag and release you should always freeze your externals to the revision they were at when the tag was created, otherwise the tag is basically still changing.
- andre_c
- Forum Contributor
- Posts: 412
- Joined: Sun Feb 29, 2004 6:49 pm
- Location: Salt Lake City, Utah
Re: Incoprorating SVN into my current workflow
Sorry, I assumed this was a development site since this code has not been run locally yet. I should have said "remote" site, not "live" site. This is just a possible solution for a non-production site with just one programmer.
By the way, it's not that difficult to get php code to run well in both linux and windows. Is there a specific problem you're running into?
By the way, it's not that difficult to get php code to run well in both linux and windows. Is there a specific problem you're running into?
-
LonelyProgrammer
- Forum Contributor
- Posts: 108
- Joined: Sun Oct 12, 2003 7:10 am
Re: Incoprorating SVN into my current workflow
Just bad experiences from the past, that's allandre_c wrote:Sorry, I assumed this was a development site since this code has not been run locally yet. I should have said "remote" site, not "live" site. This is just a possible solution for a non-production site with just one programmer.
By the way, it's not that difficult to get php code to run well in both linux and windows. Is there a specific problem you're running into?
Off topic: There was once I just couldn't get the mySQL service started or stopped till I performed some magical hack via some third party utility. But I now probably will connect straight to a remote DB rather than a local one. There was line breaks problem (now I do know about PHP_EOL, so it's a moot point) and the configuration of PHP ini files and Apache was a nightmare (setting up cookies file, having to manually point to the MySQL dll, remembering not to call the folder php...). I remembered file-system problems (Windows use c:/, linux is home\) and etc. etc.
Or I could just get a Mac, and run WinXP using VMWare