Page 1 of 1
SVN export and install scripts
Posted: Thu Mar 26, 2009 12:58 pm
by alex.barylski
How do you go about doing this?
Should I export from SVN -- tar the original files (for backup) -- delete existing then copy new files exported into location?
Over-writing seems risky -- as does possibly running a diff patch against the old files -- if this is even possible.
Anyways, just curious but how do you automate the process of exporting from SVN and re-installing the new application?
Re: SVN export and install scripts
Posted: Thu Mar 26, 2009 11:06 pm
by Chris Corbyn
Here's what we do (not with svn, but same principle):
Application installed to (for example): /usr/local/your-app-X.Y.Z
where X.Y.Z is the version number such as 1.3.5.
symlink:
/usr/local/your-app -> /usr/local/your-app-X.Y.Z
Now, when you install a new version, it doesn't overwrite anything since it creates a new directory for it's own version. You just change the symlink to reference the latest version (or in the case of a problem, to roll back just assign the symlink to a working version).
We also tag *every* release in our repository so X.Y.Z can be found as a tag if developers need to cross reference changes.
Re: SVN export and install scripts
Posted: Fri Mar 27, 2009 8:47 am
by alex.barylski
Have each version have it's own directory though, is that somewhat redundant when you could just export that revision number from SVN?
We keep our application in /var/
www.domain.com not that it matters but do I understand correct, in that each time we export, we would export to /var/production/x.y.z or similar and then update the symlink in /var/
www.domain.com to point to the latest version and rollback would be a simple matter of updating the symlink as opposed to exporting a previous version into the /var/
www.domain.com directory?
I like that idea, only exports will happen probably once a day, once a week at the minimum. I'm adovcating that everyone commit their local changes once or twice a day but to only commit working code, so that some individuals might commit every 2-3 days depending how long it takes to fic certain bugs, issues, etc.
Ideally, I will eventually get everyone on board doing unit tests and enforce a 'commit only when your tests complete' policy -- exporting at the end of the week kind of deal.
Anyways, my concern with exporting even once a week, is that the /var/development directory would have so many exports -- they would consume a ton of space, even if tar'ed.
My manager may even expect us to export daily if the bugs that are fixed are important enough.
Do you set up a cron script to drop everything but the 7 latest exports? Or do you not have this problem?
Re: SVN export and install scripts
Posted: Fri Mar 27, 2009 10:49 am
by josh
Personally I'd aim for committing every 5-20 minutes, not days. I like the symlink method, presently I just use svn update, then rsync to push the files up. I tell it to --exclude=*.svn and --delete ( delete files no longer present in source tree ). I've noticed lately sometimes our site goes down for a few seconds while we're pushing files but its usually during offpeak hours, it hasnt been a big issue yet
Re: SVN export and install scripts
Posted: Fri Mar 27, 2009 7:41 pm
by Chris Corbyn
josh wrote:Personally I'd aim for committing every 5-20 minutes, not days.
+1. Large commits are the work of the devil. Need to isolate a small breaking change and it becomes a case of remove all or nothing. There's absolutely no harm in making very small atomic commits. They don't waste a lot of space or anything.
josh wrote:I like the symlink method, presently I just use svn update, then rsync to push the files up. I tell it to --exclude=*.svn and --delete ( delete files no longer present in source tree ). I've noticed lately sometimes our site goes down for a few seconds while we're pushing files but its usually during offpeak hours, it hasnt been a big issue yet
See, using a symlink is one way to solve the downtime issue. The very last thing you do is to re-assign the symlink so it's near-instant.
To be honest, I don't know how often we purge old versions. I'll have to double-check that. Our sysadmin set it all up.
Another approach might be to make your production copy a full checkout of the repository at the correct tag, then tell Apache to deny access to .svn.
When you upgrade (or downgrade) you just need to "svn sw" to the correct tag... but again, you'll have a few seconds of downtime as the files are updated.