On Feb 27, 2005, at 12:02 PM, Basile STARYNKEVITCH wrote:
>
> I believe that SVN should version my data (and I do know which I want
> to version - I won't version object files, except in specific
> circumstances). If my data (as it is the case of a MySQL database)
> happens to be outside the realm of plain textual files, I still want
> the version control system (ie SVN) to manage it, and in my case I
> know precisely what to run to transform this data (my MySQL database)
> into a textual form easily manageable thru SVN (the mysldump
> command). And the dump (thru mysqldump command) of a MySQL database is
> much more portable and persistent than any other representation (eg
> the binary files handled by the mysqld server), and is sensibly
> handled by textual tools (like diff, patch, grep, cat...).
>
> Other scenarii where producing a textual form for SVN before commits
> is useful include:
>
> other RDBMS databases (postgresql, ...)
>
> GDBM associative files
>
> bootstrapped compilers (or processors)
>
> web pages (in some specific situations ....)
>
> binary logs transformed to verbose, textual, line-organised formats
>
> XML data (managed by some XML engine, and dumped in textual XML
> format)
>
I think you've misunderstood me: I'm not saying "a repository should
never contain anything but source code!" or, "a repository should never
contain binary data". I'm talking about expecting the the version
control system to do what a build-system should be doing.
I have to admit, I still don't quite understand what you want to do.
You want to keep *both* the binary and the textually-dumped data in the
repository, both under version control? There's certainly nothing
preventing you from doing that. You're free to keep both objects
side-by-side in the repository. But it's not the version control
system's job to "transform" things automatically. It shouldn't be
compiling code, or reformatting code, or doing database dumps. That's
why build systems exist.
Also, I'm not sure if you read the giant "warning" box on this page:
http://svnbook.red-bean.com/en/1.1/ch05s02.html#svn-ch-5-sect-2.1
A pre-commit hook script is not allowed to modify the pending commit
transaction. At most, it can validate data and reject it. So that
particular strategy is out.
It's possible for a post-commit hook to repsond to a commit by doing
some amount of server-side work -- e.g. update a 'live' website by
running 'svn update' on some server-side worknig-copy. But it can get
very messy if the post-commit hook reacts to every commit by generating
data and doing another commit: how to stop the recursion?
In essence, I'm not sure why anything needs huge automation here at
all. Keep the binary and textual files side-by-side. Let the binary
file change from normal database use. When you're ready to save
changes to the repository, run 'mysqldump' on it to generate the text
file. Then 'svn commit' both files. Heck, you could do all of this in
a nightly cron job.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 27 19:28:03 2005