On Thu, 16 Dec 2004, Ryan Schmidt wrote:
> Is it for example possible to have the SVN server do something (execute
> a shell script...) automatically on check-in, so that we could have the
> copies made immediately instead of there being an X-minute delay?
It is possible, and this is how my company does it (we use svn for web
development in several different programming environments- the pattern
is the same). Look at 'hooks' in the book.
> * The application has a database behind it. How do I track changes to
> that? If I need to make a change to the database that's incompatible
> with existing code (like renaming a field) it would seem that I would
> need to "check out" a copy of the database (the pristine copy) and then
> a second copy that I could modify, so that later a diff could be done
> between them. But I don't know of a tool to do diffs of a MySQL
> database, and there's also the problem that the database in question is
> almost half a gig in size and growing. Making even just one copy of
> that will take a non-trivial amount of time, such that it would impede
> someone's workflow to wait for such a copy to finish. We're considering
> handling database updates the way we do now -- don't version control
> them, and make potentially incompatible changes very quickly so nobody
> notices. But since we're considering version control now for the PHP
> files, I wanted to see if there's a solution for the database too.
DB versioning is a hard problem. The short answer is, you do not want to
put the DB binaries under version control. It gets you nowhere. The DB
files will be treated as binary files, and they change all the time, and
even if you captured a copy of each change (completely unrealistic,
except in extremely strange circumstances), they still will be
problematic to the DBMS, unless there was a clean DB shutdown between
each change.
There are a lot of approaches, depending on what exactly you're trying
to do. If you're primarily concerned with tracking structural changes,
the best approach we've come up with is essentially manual version
control - a change to the DB involves two files - an SQL script that
makes the change, and one that rolls it back. Those, you can version,
like any other code, and it isn't as silly as it may sound. Yes, it is a
pain, but especially when you're rolling out changes to production,
someday you'll be pleased that you wrote all those "useless" rollback
scripts.
If you don't care about the data, the easiest thing to do is to just
store the schema, and blow away the DB each time, but considering what
you wrote, I assume that's not really an option.
I don't think you are, but if you're concerned with capturing data
changes, you're actually talking about DB auditing, and my first
suggestion is to use something other than Mysql, because you can't do it
there - you need (for starters!) support for transactions and triggers.
HTH,
-j
--
Jamie Lawrence jal@jal.org
Everyone knows what damage is done to the soul by bad motion pictures.
- Pope Pius XI
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 16 21:06:37 2004