バイナリファイルであるMySQLワークベンチファイルとして管理されているデータベースを使用してプロジェクトを開発します。コミットするためにバイナリファイルの違いを簡単に伝えることはできないので、コミットする前にそのスキーマのSQL作成スクリプトを更新する必要があります。そうすれば、SQLファイルの差分を実行して、何が変更されたかを確認することができます。同じSubversionコミットに2つのファイルを含める必要がありますか？
時々、人々は忘れたり、怠け者になったりして、SQLファイルを更新しません。 Subversionを使用して、ワークベンチファイルを含むコミットにSQLファイルも含める必要があるのはどうすればよいですか？
サーバーにフックスクリプトを作成して、この要件を満たすことができます。
pre-commit-hookを使用して、ワークベンチファイルが含まれているかどうかをチェックし、コミットを中止しない場合はSQLファイルも含まれているかどうかを確認できます。
khmarbaiseの回答は機能していますが、私はあなたにもっと良い解決策を提案します。開発者にSQLファイルを強制的に編集させるのではなく、自動的に更新してみてください。つまり、ビルド・プロセスのステップ（ビルド・プロセスがあると仮定します）でWorkbenchファイルをチェックし、その更新の場合はSQLファイルを自動的に変更します。
素晴らしい解決策のようですが、MySQL WorkbenchがSQLファイルの作成をスクリプト化する方法を持っているかどうかはわかりません。私はそれを調べなければならない。 –
残念ながら、MySQL Workbenchは堅牢なコマンドラインインターフェイスを備えておらず、現時点ではこれを簡単に実行することはできません。 –
これが不可能な場合は、WorkbenchファイルでDBを作成し、SQLスクリプトを生成してみてください。原則として、同じ概念を表す2つの項目をソースコントロールに配置しないでください。それはあなたが決してありません、もう一方が変化しているときに自動的に更新してください。あなたの開発者がそれらを更新し続けるのを信頼しないでください。 – hsalimi
あなたの質問とは異なり、私はワークベンチファイルがバイナリファイルではないことを発見しました。それらは、dbのスキーマをXML形式で含むzip形式のファイルです。これらの2つの記事を参照してください：Is it possible to save MySQL Workbench files as plain XML?とSubversion diff for zipped xml file
それは本当です。私はzipがバイナリファイルなのでバイナリを言った。あなたがXMLを読むために入ると、zipにはそれがかなり嫌なものが含まれています。さらに、多くのタグには、保存ごとに変更される_ptr_属性があり、基本的なdiffは無駄になり、それらの行を除外しません。もしあなたがそうしたとしても、それはまだ変わったものを見るための低品質の方法です。 –
確かに素晴らしい解決策です。フックスクリプトを最初にカスタム修正する明確な代替案を見落とさないようにしたいと思います。 –