20

ここ数年、私は Subversion が「完全に削除」(消去) 機能を備えてくれるのを待っています。Subversion (Visual SourceSafe から来ています:p) への移行をためらっています。なぜなら、これは不可欠な機能だと思うからです。ただし、何らかの理由で、この機能は何度も延期されます。そのため、obliterate 関数を不要にする他の機能や回避策があるかどうか疑問に思い始めます。

SVN 中央リポジトリを縮小したいときはどうしますか?

例 1 :大規模なサード パーティ ライブラリをチェックインしましたが、数週間後に自分のニーズに合わないことがわかりました。その大量のデータを永久に保存してバックアップしたくありません。

例 2 : リポジトリには 10 個の大きなサードパーティ ライブラリの 10 個のバージョンがありますが、最新バージョンのみを使用しています。

例 3 : 誤って機密情報をチェックインしてしまいました ( Johnの提案による)。

例 4 : リポジトリに入れるつもりのない大きなファイルを誤ってチェックインしてしまいました。

4

13 に答える 13

19

Apache Subversionサイトsvn obliterateでは、問題のチケットについてかなりの量の議論があり、そのほとんどは2008年頃に終了します。使用はまれですが、優れた機能であるという一般的な合意があるようです。

それを望む主な理由は2つあります。

まず、機密情報のチェックインが問題になる可能性があります。リポジトリの機密性と公開のレベルによっては、そこに残して削除することは必ずしもオプションではありません。

次に、チェックインすべきではないものを大量にチェックインすると、リポジトリのサイズが大幅に増加する可能性があります。最近のディスク容量は一般的に安価ですが、無制限ではなく、ファイル容量が問題になる方法は他にもあります。ネット接続を介してリポジトリを送信する必要がある場合、それは余分な時間であり、重要な場合と重要でない場合があります。リポジトリ全体を含むCD-ROMまたはDVD-ROMを作成できることには、真の利点があります。

したがって、これは、リポジトリのダンプ、フィルタリング、およびリロードによって現在実行されている便利な機能です。私が見たレポートによると、これはエラーが発生しやすく、遅くなる可能性があり、リポジトリをシャットダウンする必要があります。

明らかに、Subversionチームにとって優先度の高い機能ではありません。かなりの数年間必要なのは、誰かが設計を考え出し、それを実装する作業を行うことです。結局のところ、それは非常にまれに行われるべきであり、回避策があります。ただし、Subversionで多くの作業を行いたい場合は、(十分な品質であれば)おそらく実装されるパッチを提供できます。

于 2010-03-11T16:10:19.463 に答える
11

ソース管理の意味に反します。
ソース管理とは、以前の状態を復元できることです。ファイルを完全に削除すると、削除できなくなります。

OTOH 私はVSSを知らないので「完全に削除」と誤解しているかもしれません

于 2010-03-11T15:15:07.560 に答える
8

これに反対する明らかな理由は、バランスを取れば SVN を悪化させると開発者が考えているためです。不必要なものを削除できるという幸福感は、うっかり何かを消し去って /trunk がなくなってしまったときの怒りによって、はるかに小さくなります。

FogBugz もまったく同じ動作をします。彼らの場合は、完全に設計によるものであり、ユーザーを自分自身から保護していると私は信じています。

于 2010-03-11T15:16:10.097 に答える
7

Obliterate は、必要なバージョン管理の原則に違反しています。スペースを節約できないか、以前のタグが壊れてしまいます。ファイルを消去した場合、真の以前のバージョンに戻ることはできません。

リポジトリの成長に関するコメントについては... どのリポジトリも、時間の経過とともに変更のサイズに比例して成長します。それがソース管理システムの要点です。以前のバージョンを追跡できる必要がない場合は、どこかの共有フォルダーに固執してみませんか?

于 2010-03-11T15:16:21.100 に答える
6

忘れられた機能である Subversion Obliterateを引用すると、質問には、問題理由、および解決策の 3 つの要素があります。解決策への質問から始めたので、それから始めます。

解決

お気づきのように、優れた解決策はありません。特に大規模な企業リポジトリを扱っている場合は、リポジトリが大きくなるほどソリューションが難しくなるためです。不要なものをレポから一掃できるダンプ/フィルターと呼ばれる機能がありますが、それほど使いやすくなく、高速でもなく、信頼性もありません。

2008 年以降、svn チームは抹消機能をそこに入れるための小さな努力(スレッドをたどる) がありましたが、その努力は静かな死に終わりました。

問題

冒頭で述べた記事には、実際には消去コマンドが必要なユースケースの優れたリストがあり、開発者は実際にそのメリットを認めた516 号スレッドで.

残念ながら、今では手遅れのようです。後で追加されなかった本当の理由は、最も基本的なレベルでコードにフックされるため、実装がほぼ不可能になったためです (ソリューションの下の小さな労力のリンクも参照してください)。

よくある質問のエントリから:

リビジョンは、相互に構築される不変のツリーです。履歴からリビジョンを削除すると、ドミノ効果が発生し、後続のすべてのリビジョンに混乱が生じ、すべての作業コピーが無効になる可能性があります。

理由

問題は、真のバージョン管理の原則に準拠していないため、当初は抹消機能が却下されたことです。

再びFAQエントリから:

リポジトリの履歴からファイルを完全に削除するにはどうすればよいですか? ファイルまたはコミットのすべての証拠を破棄したい特殊なケースがあります。(誰かが誤って機密文書をコミットした可能性があります。) これはそれほど簡単ではありません。なぜなら、Subversion は意図的に情報を失わないように設計されているからです。

でも

私は現在、より大きなチームとより大きなプロジェクトを持つ多くのクライアントのためにSVNを使用してきましたが、基本的に実際の問題はありませんでした. はい、言及された使用例は完全な機能を保証しますが、これまでのところ、これがどこに行っても何度も何度も発生する問題であるとは確信していません. もちろん、この特定の問題の性質は、一度間違えただけで、適切に元に戻すことができないということです。

于 2012-05-27T18:36:50.623 に答える
5

ダンプとロードを行うことで、SVN リポジトリのサイズを減らすことができます。基本的に、数年以上前のものに戻したくないと言う場合は、リポジトリをダンプし、時間に基づいてフィルタリングしてから、ダンプをリロードすることができます。サイズが原因で 1 つのファイルを削除したいということは、そのファイルがそもそもソース管理システムに属していなかったことを示している可能性があります。

于 2010-03-11T15:20:58.750 に答える
5

データを消去するのに役立つスクリプトがいくつかあります。詳細については、このメーリング リストのスレッドに従ってください。

バージョン管理の本質は、データを完全に削除するのではなく、データを失わないことであるため、これを行うのは難しい方法です。しかし、1年に1回程度の剪定をすれば大丈夫です。

于 2010-03-11T15:22:45.597 に答える
4

リポジトリからデータを削除すると、ソース ツリーの以前の状態と変更をすべて再現できるというソース管理の基本的な前提が崩れるためです。バージョン管理から何かを消去したい場合、彼らが言うように、おそらく「やり方が間違っている」でしょう。

于 2010-03-11T15:16:35.750 に答える
4

私は約 15 年間、さまざまなバージョン管理システムを使用していますが、このような機能は必要ありませんでした。

その機能が必要な理由は何でしょうか。

  • ディスクスペース?ディスク容量の価格を考えると信じがたい
  • パスワードをバージョン管理にコミットしましたか? それはあなたに教えてくれます。行ってパスワードを変更する
  • リポジトリの速度?そうは思えませんが、おそらくパフォーマンスが優れていると思われるまったく異なるシステムを検討するとします。
于 2010-03-11T15:18:32.250 に答える
3

ソース管理の全体的なポイントは、リポジトリがどのように見えるかの完全な履歴を持つことです。このobliterateコマンドは、ソース管理のこの目的を無効にし、このコマンドを使用するすべてのバージョン管理システムの誤機能です。

SVN には、ファイルの完全なコピー (変更されたビットのみ) を必要としない安価なコピーと安価な分岐があります。その中央リポジトリは通常、サイズが非常に管理しやすいため、この誤機能は不要です。

于 2010-03-11T15:16:53.937 に答える
2

最後に、それが ADMIN 機能として意図されていることを確認しましたが、管理者はすでにダンプ/フィルター/broken_workaround して履歴を削除できます。監査証跡に関しては、これは現在の引用を変更しません。何かを絶対に取り除かなければならない場合、それはそれほど恐ろしいことではありません.

Svnadmin obliterate は、最もリクエストの多かった機能の 1 つであり、開発者は最終的にそれが存在することを認めました (ついに! 8 年後!!!)。そして、それが存在しないという宣伝は、SVN からユーザーを追い出しています。

残念ながら、私はこの「欠けている機能」について難しい方法で学ばなければなりませんでした。基本機能が機能になったのはいつからですか? 新しいユーザーはこれについて聞き始め、SVN を避けています。私に関して言えば、今は Git を使っています。

私の意見が気に入らない?Linus は SVN の開発者たちをバカと呼んでおり、中央集権型システム全体に欠陥がありました。私はライナスを真の専門家として信頼しており、特に彼は情報源についてよく知っています。

于 2011-07-14T15:55:00.273 に答える
1

Obliterate は Subversion の必須機能ではありません。バージョン管理の基本原則 (つまり、すべての履歴を記録すること) を実際に破るためです。

とにかくこれを行うための回避策があるため(svnadminとフィルタリングを使用)、これは必須の機能ではありません。

また、この機能は現在鋭意開発中です。詳細については、この投稿を参照してください。

于 2010-03-12T14:06:27.407 に答える
0

私がしていること - サブバージョンを使用しないでください。ごめん。

彼ら(開発者)は、それが重要な機能であるというあなたの評価に明らかに同意していません。私が現在働いている会社がそれを使用するのを止めませんでした;) 私は個人的に、この正確な理由から転覆を除外します.

于 2010-03-11T15:12:12.547 に答える