Is it safe to commit more files as a pre-commit hook?

Question

I want to automatically commit the database when we copy files from one branch to the other in Subversion. Is it safe to use svn commmit as part of a pre-commit hook assuming that we do it in very specific cases?

Answer 1

It sounds like a dubious proposition - regardless of which VCS (version control system) you use. As ever, in detail, "it depends".

The first problem is 'what does it mean to "commit the database"'? Presumably, you are thinking in terms of a database stored in a single file, and you'd do a simple commit of the file as a binary chunk of data. That assumes that no-one else is using the database. The main DBMS provide tools for ensuring a coherent backup of the database even if it is in use at the time. If your DBMS has a server running, it may get rather unhappy if you quietly have a VCS do the check-in. The typical VCS will remove the currently extracted file and replace it with the new version (in case there are keywords to be expanded in it, for example). You'd have to ensure that keywords are not expanded in the DBMS file. What happens when the database grows and occupies more than one space?

I'd be more inclined to ensure that there's a backup of the database and then version control that. But this depends a lot on what your DBMS provides in the way of backup facilities (and restore facilities -- I assume the intention is to be able to restore the database if needed).

Finally, for most systems, the contents of the database are not particularly important; what is crucial tends to be the schema of the data - the tables, columns, indexes, constraints, stored procedures, views, permissions, ... The actual data rows is usually of minimal significance.

Answer 2

The commit itself is safe in SVN. In case your version is obsolete when you're committing, the operation will be rejected. Of course, committing binary file in SVN makes it impossible for you to do some svn-based conflict resolving, which is sad...

What you should worry about is svn update. You said that you'd like to store database in SVN. As well as I know neither MySQL, Oracle nor MS-SQL like it when user plays with their datafiles... You can do that, but the database configuration file should be stored in SVN as well. And maybe logs too. And of course - the RDBMS shouldn't be running when you perform an update. Quite a lot of fuss, isn't it?

You can also lock files using SVN command to disallow modification by other user.

Considering all this - maybe there are other, better suited solution for you than storing binary database file in a text-oriented version control system?

Answer 3

Even if it's safe, it probably doesn't have the effect you would expect.

When you're in pre-commit the new transaction has already been created, but not committed. You have access to that information to do your work, but an additional svn commit would create a separate transaction that is also not committed, yet.

That new transaction wouldn't see any of the changes in your current transaction, because it hasn't been finalized, yet.

You probably want some custom scripts you run to do this for you, maybe part of your build system.

Additionally, you need a working copy to commit from, you don't have that where the pre-commit hook runs, on the server. You might be able to cobble something together with a shared working copy and hope no two people cause the pre-commit hook to run at the same time, but again, you're probably better off with a custom scripting solution.

Answer 4

Even if it's safe, it sounds like something that's going to confuse the heck out of your users. They asked for X to be committed, and X+Y got committed. That's a recipe for people having no clue what's going on. Especially when you try to add new team members.

I'd also like to note that even if this works OK, it sounds like an edge condition for VCS operation to me. And I've learned over the years not to push my tools too hard toward the edges without a darn good reason. Edge conditions are where bugs tend to crop up, and I'd be worried that something could change to break this in the future.