Backups/version controll/source controll

Hi,

i was wondering if there was some kind of program i could download to
keep track of my rails applications; something in the vicinity of
subversion (a open-source backing-up tracking program - i.e to keep
track of my applications once they are on the net, during a q&a period,
where i’d be changing my application periodicly, but keeping a current
version on the net, and one back on my local host server) but something
that fits in with rails apps.
does this kind of thing exist, or should i just go with a regular
back-up program i find off the net?

thanks in advance,

shai

On Mon, Jul 10, 2006 at 04:51:21PM +0200, shai wrote:

i was wondering if there was some kind of program i could download to
keep track of my rails applications; something in the vicinity of
subversion (a open-source backing-up tracking program - i.e to keep

What OS are you doing your development and production work on? What
database? It all makes a big difference.

Subversion is pretty much the best thing to use for controlling your
file versions; however you’ll end up with some interesting production
files not being covered by svn (like logs, and the database itself).

I’d recommend using rdiff for keeping offsite versions of your
production site; perhaps having database dumps taken and included in the
rdiff tree (using mysqldump, if you’re on mysql). But you must check
that you can restore your entire site from the backups, otherwise
they’re worthless.

-jim

On 7/10/06, Jim C. [email protected] wrote:

files not being covered by svn (like logs, and the database itself).

I’d recommend using rdiff for keeping offsite versions of your
production site; perhaps having database dumps taken and included in the
rdiff tree (using mysqldump, if you’re on mysql). But you must check
that you can restore your entire site from the backups, otherwise
they’re worthless.

My vote is for Subversion as well, it’s pretty painless to deal with
if you’re careful of what Jim was pointing out. Also, don’t be tempted
to let subversion handle all the webwork for you, it can get slow when
you have a load of files.

At our firm the new policy is to develop on our own work computers,
commit when we’re happy, and when all the testing is done we checkout
a copy into the staging folder where we can see how it’ll do on the
real server. Finally if that all checks out we checkout a copy to the
live area of the server and go home for the evening.

As Jim points out any dynamic areas won’t be well covered by
subversion so if you need the logs for your production site you’ll
have to set up a svn hook to commit those files or use a cron script
however often. Either way will probably break at some point so be
careful and do it manually occasionally.

Lastly, svn doesn’t keep track of permissions so remember to check
that tmp, log, and public have write access and that your dispatch has
execute (which subversion will track if you get into the subversion
properties but I don’t know how so I just say to check it.) They have
a pretty distinct smell when the perms are wrong so if you see
Application Error but no log output then you have your criminal in
most cases.

We also replicate the entire mysql database to each test box via the
built-in replication. It’s really heavy-weight but it works nicely for
those that don’t have the mysql server in the office.

Hope that helps,
Chuck V.