会社の Subversion サーバーをバージョン 1.6 から 1.7 にアップグレードします。サーバーはLinux（Ubuntu AFAIK）で実行されます。
私はそれらすべてを読みました：
私はそれらの投稿も読みました：
subversion-client-version-confusion
アップグレード方法-svn-server-from-1-6-to-1-7
今ここで、私はこれを実行する方法を知っています。大したことじゃないよ。私が最も懸念しているのは、現在のフック インフラストラクチャです。bash と perl にはいくつかのスクリプトがあります。
今のところ、フック インフラストラクチャの変更に関する情報は見つかりませんでしたが、見逃した既知の問題がいくつかあるのではないでしょうか? 知っておくべきアップグレードに反対するものはありますか?
PS:Try and see what comesメソッドは絶対に利用できません。アップグレードはできるだけ流暢にしてほしいです。リポジトリのユーザーは変更に気付かないはずです。その点で失敗は許されない。
フックをどうするかにもよると思います...
フックが を使用している場合、svnlook問題はないはずです。API (Python API など) を使用している場合は、何らかの操作を行っている限り、おそらく問題ありませsvnlookん。
問題に直面し始める可能性があるのは、突いたり突いたりしてはならない場所を突いたり突いたりする場合です。たとえば、 を行う代わりにsvnlook、 を行いますsvn。パラメータが変更された場所がいくつかあります。また、svn checkout (フックでの絶対的な no-no) を実行してから.svnディレクトリを調べると、驚くことでしょう。ルールに従って行に色を付ければ、フックに問題はありません。
私はリビジョン 1.1 からリビジョン 1.7 にかけて、正常に動作するフック フックに影響を与える問題を知りません。また、Subversion 1.x を使用している限り、問題は発生しないと思います。Subversion 2.x が登場すると、すべての賭けはオフになります。
はい、フックの動作にいくつかの変更がありました。start-commit フックには、バージョン 1.4 以前にはなかった追加のフィールド (機能フィールド) がありますが、現在のフックには影響しません。また、Subversion 1.5 または 1.6 では、ユーザーはコミット時にリビジョン プロパティを設定できるようになりました。これらは現在のフックには影響しませんが、現在のフックに組み込みたい機能である可能性があります。
メソッドが絶対に利用できないものを試してみてください...
はい、試してみて、何が来るかを確認する方法が利用可能です。Subversion 1.6 環境のコピーを作成し、Subversion 1.7 に変更を加えて、すべてが正しくなるまでテストします。
コピーしてテストしない限り、静かなアップグレードという目標を達成する方法がわかりません。
Subversion との互換性により、フック スクリプトが 1.6 と 1.7 でまったく同じように呼び出されることが保証されます。1.7 (および将来のバージョン) では、より多くの引数をスクリプトに渡すことができますが、古い引数は依然として古い動作と一致します。したがって、テンプレートのようにスクリプトを作成した場合、「余分な」引数を無視するために違いは見られません。
Subversion 1.7 は 1.6 以降のリポジトリ形式を変更していないため、アップグレード後に (偶然にも) 1.6 の svnlook を使用してリポジトリにアクセスすることもできます。
アップグレードが実行され、成功しました。Subversion サーバーは問題なく更新されました。フックは、ルールと常識を尊重して、ハックやスラッシュなしで設計されました。それはリスクがありましたが、有望であり、有益でした (チェックアウトは今では光速です)。
完全を期すために、集中管理されたクライアントのアップグレードが連続して行われました。問題もありましたが、重大ではなく、予測可能ではありませんでした。svn client 1.6 -> 1.7.7 への移行後、作業コピーの形式が変更されました。既存のすべての作業コピーを手動でアップグレードする必要がありました (または、ワイプアウトして、クリーンな状態で再度チェックアウトする必要がありました)。
ただし、サーバーのアップグレードは安全です。