Re: versioning a [small] MySQL database with svn?

Le Sun, Feb 27, 2005 at 11:30:11AM -0600, Ben Collins-Sussman écrivait/wrote:
>
> On Feb 27, 2005, at 11:03 AM, Basile STARYNKEVITCH wrote:
> >
> >I believe that this is a common scenario that one want to version a
> >file produced by a command (be it a RDBMS dump, or an HTTP client like
> >wget, or a GDBM dump...) and to ensure that the SubVersion system
> >produces this file (by running this command) before commits.
>
> Actually, no, in the general world of version control, it's considered
> a Bad Practice to put "derived" files under version control. For
> example, one doesn't put compiled (.o) files or binaries into the
> repository. It's the *source* that gets managed, not the derived
> objects.

I knew that, but with e.g. MySQL databases, it is a very bad practise
to backup (or manage under version control) the MySQL binary data
files [those under /var/lib/mysql/foo_db/ on my Debian linux machine]
and it is extremely recommanded to backup using the output of
mysqldump command. And on my example with MySQL, the source is the
MySQL database itself which is not a file, or a collection of files,
or a directory tree (accessible to ordinary users). The only mean I
can access to my MySQL database is thru SQL requests in the
libmysqlclient library, which is what the mysqldump does for me.
>
> The point of the start- and pre-commit hook scripts are to enforce
> certain standards, not to generate more data to put in the
> repository.

I don't want to "generate" the data, but I just want to "transform"
the data (a MySQL database in my example and my current concern) into
a form (textual dump files produced by mysqldump) easily and safely
manageable by SVN.
>
> For example, people often ask if it's possible to make the pre-commit
> hook reformat code before putting it in the repository. The answer is,
> "no, but it can be used to *reject* any commit that doesn't conform to
> code formatting standards."
>
> The sort of things you talk about above (making sure Subversion
> "produces a file" before commits) is the domain of your build system,
> not your version control system.

I do know that versioning systems usually don't produce files (BTW, I
used several versioning systems before, my first experience was SCCS
fifteen years ago), but in our world more and more data is not local
files (as my MySQL example shows) - and there are some good reasons to
version some produced file (another common example is a bootstrapped
language implementation - then you want to version-control some form
of "compiled" file, a concrete example I do know quite well is the CVS
of Ocaml -see http://caml.inria.fr/ for more - which contains the
byte-compiled form of the Ocaml compiler, which is necessary to
compile the Ocaml compiler [written itself in ocaml]).

So I respectfully disagree with your current position, even if I did
share it a dozen years ago (when using SCCS, or RCS, or CVS), in the
old time where the only important data I managed (and wanted to
version) was the textual sources files I typed. This is definitely not
the case now, I do want to manage under version control a small MySQL
database (and I could manage also a GDBM binary file -dumpable into a
textual representation- or some kind of XML store).

In addition, MySQL dumps (produced with mysqldump command) are textual
files, which are easily diff-able and patch-able. So there is a point
to wanting the subversion system to mysqldump a (rather small)
database and version the produced dump. It would be foolish to
version-control the mysql binary data files (because you can't
guarantee their integrity while mysqld is running).

We probably both stand at our [previous] position, but I hope I have
given more arguments to defend mine. I fully respect, and still
disagree with, your position (which I happenned to have a dozen years
ago).

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)

It is perfectly sensible to manage all above under a version control
system like SVN (or CVS or Darch or RCS ...) and it is extremly useful
to run a conversion command before commiting. This conversion command
is not a build step - it is a step inside the backup & versioning
procedures!

A big thanks for your reply! Kind regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org