On Sun, 27 Feb 2005 19:02:23 +0100, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
> 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.
While I understand Mr. Collins-Sussman's point, I respectfully
disagree as well, Certainly, from the perspective of
"responsibility", it's reasonable to expect that a version control
system only consider the integrity of data once it crosses over into
the repository. In this light, server-side hooks which reject
"inconsistent" changes are enough; it's the commiter's job to do
whatever is necessary to generate appropriate data before committing
it. From the perspective of "utility" (or perhaps "convenience" or
"laziness"), I can see the benefit in integrating well-defined
"transformations" (be they changes in file or changes in properties)
into the version control system's file transfer process. True, these
could be done manually, via a build script, or via a wrapper around
the svn invocation on the client side. But it'd be nice to link them
in a more automagic way to the process of committing changes.
As a minimally-invasive option, perhaps it'd be possible to use two
client-side hooks: a 'prior-to-sending' hook, which would be called
before committing, importing, (and possibly exporting) a file, and an
'after-receiving' hook, which would be called after checking out or
updating a file. Each might be told the name of the file and the
operation involved. I don't think either could create an inconsistent
state of the working copy, as long as it didn't play around with
.svn-ish internals.
It would certainly be possible to affect more indirect relationships:
if an 'after-receiving' hook made changes to a file, then that file
would still show as locally modified after 'svn update', and if a
'prior-to-sending' hook modified a file, then 'svn' diff' prior to the
commit and 'svn diff -r PREV:COMMITTED' would show different changes.
Caveat scriptor.
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
---------------------------------------------------------------------
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:42:33 2005