Consider this a work in progress, but here is the latest script I'm using to pull the latest RC from SVN nightly:
http://fak3r.com/articles/2006/05/31/roundcube-webmail-update-script
Feedback, criticisms appreciated.
P
http://fak3r.com - you don't have to kick it
Why not "svn update"? It takes puts less bandwidth on both
servers, and runs much quicker.
On Thu, 1 Jun 2006, phil wrote:
Consider this a work in progress, but here is the latest script I'm using to pull the latest RC from SVN nightly:
http://fak3r.com/articles/2006/05/31/roundcube-webmail-update-script
On Thu, 1 Jun 2006 14:12:49 -0400 (EDT), Jon Daley roundcube@jon.limedaley.com wrote:
Why not "svn update"? It takes puts less bandwidth on both servers, and runs much quicker.
Ah, but then why not "svn up"? Even quicker! ;)
So sure, it would remove the need to press 'p' on the first SVN run, since it wouldn't be using https, but I was going by the RC Wiki page: http://trac.roundcube.net/trac.cgi/wiki/Dev_SVN
Any reason to use the https way vs a basic svn up?
Thanks for the feedback Jon.
P
On Thu, 1 Jun 2006, phil wrote:
Consider this a work in progress, but here is the latest script I'm
using to pull the latest RC from SVN nightly:
http://fak3r.com/articles/2006/05/31/roundcube-webmail-update-script
On Thu, 1 Jun 2006, phil wrote:
On Thu, 1 Jun 2006 14:12:49 -0400 (EDT), Jon Daley roundcube@jon.limedaley.com wrote:
Why not "svn update"? It takes puts less bandwidth on both servers, and runs much quicker.
So sure, it would remove the need to press 'p' on the first SVN run, since it wouldn't be using https, but I was going by the RC Wiki page: http://trac.roundcube.net/trac.cgi/wiki/Dev_SVN
No. It uses the same URL as the first run (and you still have to
do a 'svn checkout' once), but since you already checked it out once, it doesn't have to get every file, but instead just the stuff that has changed since your last update.
Any reason to use the https way vs a basic svn up?
Hopefully this isn't an insult, but have you used subversion
before? I don't understand the question.
On Thu, 1 Jun 2006 14:53:36 -0400 (EDT), Jon Daley roundcube@jon.limedaley.com wrote:
On Thu, 1 Jun 2006, phil wrote:
On Thu, 1 Jun 2006 14:12:49 -0400 (EDT), Jon Daley
roundcube@jon.limedaley.com wrote:
Why not "svn update"? It takes puts less bandwidth on both servers, and runs much quicker.
So sure, it would remove the need to press 'p' on the first SVN run,
since it wouldn't be using https, but I was going by the RC Wiki page:
No. It uses the same URL as the first run (and you still have to do a 'svn checkout' once), but since you already checked it out once, it doesn't have to get every file, but instead just the stuff that has changed since your last update.
Any reason to use the https way vs a basic svn up?
Hopefully this isn't an insult, but have you used subversion before? I don't understand the question.
no, not insulted at all. I've used CVS for years, and I've used SVN from my days with Hula a year or so back, but yeah, looking at my script for that it just did a 'svn up' to get the latest code before the build. I guess what I did was looked up the 'dev' way to do it, (wiki link) then did it that way, saw that it put it in ./trunk/roundcubemail and I knew I didn't want ${WEB_ROOT}/trunk/roundcubemail - I wanted ${WEB_ROOT}/roundcubemail and that's why I have the full checkout each time and the mv commands. That's really kinda dumb though no reason in taxing the server for all the files each time, lemme read up on svn, maybe you can set a target dir to put the files for checkout/update?
Thanks for the feedback, I've never written a script and left it alone for long.
P
http://fak3r.com - you don't have to kick it
On Thu, 1 Jun 2006 14:32:17 -0600, Eric Stadtherr estadtherr@gmail.com wrote:
Phil,
You probably don't want to have your SVN working copy in your web space.� It forces your webserver to deal with the subversion files in the .svn directories, and potentially opens you up to breaking your live server when playing around with something.� I keep my working copy in a development location (~/dev/roundcube), and I can do updates, merges, etc. from there.� When I want to deploy my working copy, I wrote a little script that copies everything over to the web space (/Library/WebServer/Documents/roundcube) while excluding the .svn directories, backup files, temporary files, etc., and then sets the permissions to the www user.� Anyone care to see the script?
Yes, please; I've made changes to my script thanks to Jon's comments, and I'd like to see how you've done it. I agree that having the .svn files in the webroot is a bad idea too. Hmmm, this is fun though!
P
�
On Thu, 1 Jun 2006 15:17:01 -0500, phil wrote: On Thu, 1 Jun 2006 14:53:36 -0400 (EDT), Jon Daley wrote:
On Thu, 1 Jun 2006, phil wrote:
On Thu, 1 Jun 2006 14:12:49 -0400 (EDT), Jon Daley
wrote:
Why not "svn update"? It takes puts less bandwidth on both servers, and runs much quicker.
So sure, it would remove the need to press 'p' on the
first SVN run,
since it wouldn't be using https, but I was going by the RC
Wiki page:
No. It uses the same URL as the first run (and you still have to do a 'svn checkout' once), but since you already checked it
out once, it
doesn't have to get every file, but instead just the stuff that
has
changed since your last update.
Any reason to use the https way vs a basic svn up?
Hopefully this isn't an insult, but have you used subversion before? I don't understand the question.
no, not insulted at all. I've used CVS for years, and I've used SVN from my days with Hula a year or so back, but yeah, looking at my script for that it just did a 'svn up' to get the latest code before the build. I guess what I did was looked up the 'dev' way to do it, (wiki link) then did it that way, saw that it put it in ./trunk/roundcubemail and I knew I didn't want ${WEB_ROOT}/trunk/roundcubemail - I wanted ${WEB_ROOT}/roundcubemail and that's why I have the full checkout each time and the mv commands. That's really kinda dumb though no reason in taxing the server for all the files each time, lemme read up on svn, maybe you can set a target dir to put the files for checkout/update?
Thanks for the feedback, I've never written a script and left it alone for long.
P
http://fak3r.com [3] - you don't have to kick it
�
Links:
Yes, I almost wrote to say you might be more interested in a setup
that subversion calls "vendor branches". The script to copy from a subversion repository to your web directory should be pretty easy, see "svn export". You don't need a subversion server to run that, but you can just run it on your local files.
On Thu, 1 Jun 2006, Eric Stadtherr wrote:
Phil,
You probably don't want to have your SVN working copy in your web space. It forces your webserver to deal with the subversion files in the .svn directories, and potentially opens you up to breaking your live server when playing around with something. I keep my working copy in a development location (~/dev/roundcube), and I can do updates, merges, etc. from there. When I want to deploy my working copy, I wrote a little script that copies everything over to the web space (/Library/WebServer/Documents/roundcube) while excluding the .svn directories, backup files, temporary files, etc., and then sets the permissions to the www user. Anyone care to see the script?
On Thu, 1 Jun 2006 15:17:01 -0500, phil wrote:
On Thu, 1 Jun 2006 14:53:36 -0400 (EDT), Jon Daley roundcube@jon.limedaley.com wrote:
On Thu, 1 Jun 2006, phil wrote:
On Thu, 1 Jun 2006 14:12:49 -0400 (EDT), Jon Daley
roundcube@jon.limedaley.com wrote:
Why not "svn update"? It takes puts less bandwidth on both servers, and runs much quicker.
So sure, it would remove the need to press 'p' on the first SVN run,
since it wouldn't be using https, but I was going by the RC Wiki page:
No. It uses the same URL as the first run (and you still have to do a 'svn checkout' once), but since you already checked it out once, it doesn't have to get every file, but instead just the stuff that has changed since your last update.
Any reason to use the https way vs a basic svn up?
Hopefully this isn't an insult, but have you used subversion before? I don't understand the question.
no, not insulted at all. I've used CVS for years, and I've used SVN from my days with Hula a year or so back, but yeah, looking at my script for that it just did a 'svn up' to get the latest code before the build. I guess what I did was looked up the 'dev' way to do it, (wiki link) then did it that way, saw that it put it in ./trunk/roundcubemail and I knew I didn't want ${WEB_ROOT}/trunk/roundcubemail - I wanted ${WEB_ROOT}/roundcubemail and that's why I have the full checkout each time and the mv commands. That's really kinda dumb though no reason in taxing the server for all the files each time, lemme read up on svn, maybe you can set a target dir to put the files for checkout/update? Thanks for the feedback, I've never written a script and left it alone for long. P -- http://fak3r.com - you don't have to kick it
Jon Daley http://jon.limedaley.com/
Things should be made as simple as possible, but no simpler. -- Albert Einstein
On Thu, 1 Jun 2006, phil wrote:
saw that it put it in ./trunk/roundcubemail and I knew I didn't want ${WEB_ROOT}/trunk/roundcubemail - I wanted ${WEB_ROOT}/roundcubemail and that's why I have the full checkout each time and the mv commands. That's really kinda dumb though no reason in taxing the server for all the files each time, lemme read up on svn, maybe you can set a target dir to put the files for checkout/update?
svn update doesn't take a target directory, but svn checkout can,
and you can also specify the source to be a more complete path, like trunk/roundcubemail instead of just trunk, that might get the path that you want.
On 1 Jun 2006, at 21:17, phil wrote:
lemme read up on svn, maybe you can set a target dir to put the
files for checkout/update?
The command svn co https://svn.roundcube.net/trunk/roundcubemail/ target-folder/ Should check out the trunk/roundcubemail directory into target-folder/
I've done a take on your script over at http://beer-monkey.com/
articles/2006/06/01/roundcube-update-script
I use chmod instead of the chown line that your script uses since if
we're installing into or updating a shared environment, it's not too
likely that the user will be allowed to chown to the www user or group.
Yours, Craig -- Craig Webster | t: +44 (0)131 516 8595 | e: craig@xeriom.net Xeriom.NET | f: +44 (0)131 661 0689 | w: http://xeriom.net
I made the script available at:
http://stadtherr.bounceme.net/files/install.csh
Usage is simple. Place the install.csh at the top level of your
roundcubemail working copy directory, and run:
# install.csh <destination>
For example, on my webserver I run:
# install.csh /Library/WebServer/SecureDocuments/roundcubemail
Voilà!
It will happily copy on top of an existing installation, but it won't
remove any files in the destination that aren't in the working copy
(i.e. it doesn't do a "sync" just a "copy over").
On Jun 1, 2006, at 2:49 PM, Phil Cryer wrote:
On Thu, 1 Jun 2006 14:32:17 -0600, Eric Stadtherr
estadtherr@gmail.com wrote:Phil,
You probably don't want to have your SVN working copy in your web space.� It forces your webserver to deal with the subversion files in the .svn directories, and potentially opens you up to breaking your live server when playing around with something.� I
keep my working copy in a development location (~/dev/roundcube), and I
can do updates, merges, etc. from there.� When I want to deploy my
working copy, I wrote a little script that copies everything over to the web space (/Library/WebServer/Documents/roundcube) while excluding the .svn directories, backup files, temporary files, etc., and then sets the permissions to the www user.� Anyone care to see the script?Yes, please; I've made changes to my script thanks to Jon's
comments, and I'd like to see how you've done it. I agree that
having the .svn files in the webroot is a bad idea too. Hmmm, this
is fun though!P
�
On Thu, 1 Jun 2006 15:17:01 -0500, phil wrote: On Thu, 1 Jun 2006 14:53:36 -0400 (EDT), Jon Daley wrote:
On Thu, 1 Jun 2006, phil wrote:
On Thu, 1 Jun 2006 14:12:49 -0400 (EDT), Jon Daley
wrote:
Why not "svn update"? It takes puts less bandwidth on both servers, and runs much quicker.
So sure, it would remove the need to press 'p' on the
first SVN run,
since it wouldn't be using https, but I was going by the RC
Wiki page:
No. It uses the same URL as the first run (and you still have to do a 'svn checkout' once), but since you already checked it
out once, it
doesn't have to get every file, but instead just the stuff that
has
changed since your last update.
Any reason to use the https way vs a basic svn up?
Hopefully this isn't an insult, but have you used subversion before? I don't understand the question.
no, not insulted at all. I've used CVS for years, and I've used SVN from my days with Hula a year or so back, but yeah, looking at my script for that it just did a 'svn up' to get the latest code before the build. I guess what I did was looked up the 'dev' way to do it, (wiki link) then did it that way, saw that it put it in ./trunk/roundcubemail and I knew I didn't want ${WEB_ROOT}/trunk/roundcubemail - I wanted ${WEB_ROOT}/roundcubemail and that's why I have the full checkout each time and the mv commands. That's really kinda dumb though no reason in taxing the server for all the files each time, lemme read up on svn, maybe you can set a target dir to put the files for checkout/update?
Thanks for the feedback, I've never written a script and left it alone for long.
P
http://fak3r.com [3] - you don't have to kick it
�
Links:
Eric Stadtherr wrote:
I made the script available at:
http://stadtherr.bounceme.net/files/install.csh
http://stadtherr.bounceme.net/files/install.cshUsage is simple. Place the install.csh at the top level of your roundcubemail working copy directory, and run: # install.csh <destination>
For example, on my webserver I run:
# install.csh /Library/WebServer/SecureDocuments/roundcubemail
Voilà!
It will happily copy on top of an existing installation, but it won't remove any files in the destination that aren't in the working copy (i.e. it doesn't do a "sync" just a "copy over").
You may want to also take a look at Phing (http://phing.info) for these types of deploy/install scripts. Phing is basically Apache Ant but written in PHP. We use Phing quite heavily at work for these types of deployment tasks (and running phpunit tests, building selenium scripts, etc. etc.). It's particularly useful for copying sets of files with explicit inclusions & exclusions.
Cheers, Hans
-
Craig Webster -
Eric Stadtherr -
Hans L -
Jon Daley -
phil -
Phil Cryer