16

私が働いている会社は立ち上げ中で、その過程で名前が変わりました。そのため、ファイルの変更履歴やバージョン間の祖先のリンクなど、壊れる可能性のあるものを壊すことを恐れているため、パッケージ名 com.oldname を引き続き使用しています (正しい用語を使用しているとは思いませんが、概念は理解できます)。 ）。

使用するもの: Eclipse、TortoiseSVN、Subversion

.svn フォルダーの内容と Java ファイルのパッケージ名との間の不一致を防ぐために、多くの手順でそれを行う必要があることをどこかで見つけました。

  • 最初に TortoiseSVN を使用してディレクトリの名前を変更し、.svn ディレクトリを更新します。
  • 次に、ディレクトリの名前を手動で元の名前に戻します。
  • 最後に Eclipse を使用してパッケージの名前を変更し (リファクタリング)、Java ファイルを更新して新しい名前に戻します。

それは私には良いことのように思えますが、祖先や歴史、その他すべてが一貫してうまく機能するかどうかを知る必要があります.

私はそのサーバーへの鍵を持っていません。そのため、急いでバックアップを取ったり、1 つまたは 2 つのことを試したりすることはありません。やらない正当な理由や、うまくいく方法を考えてみたいと思います。

ご協力ありがとうございました、

M.ジョアニス

パッケージの名前変更テスト

手順：

  1. 新しいパッケージ com.oldname.test.renametest.subpackage を作成します。

  2. renametest の下に RenameTest0.java という名前の新しいクラスを追加し、以下を含みます。

    クラス RenameTest0 {
    public RenameTest0() {
        showMessage();
        新しい RenameTest1();
    }
    public static void showMessage() {
        System.out.println("RenameTest0!");
    }
    public static void main(String[] args) {
        新しい RenameTest0();
    }
}

  3. 以下を含む renametest.subpackage の下に新しいクラスを追加します。

    クラス RenameTest1 {
    public RenameTest1() {
        showMessage();
        RenameTest0.showMessage();
    }
    public static void showMessage() {
        System.out.println("RenameTest1!");
    }
}

  4. RenameTest0 が正常に動作することをテストします。

  5. 専念。
  6. 両方のクラスのメッセージを変更します。
  7. 専念。
  8. ここでも、1 つのクラスのメッセージを変更してコミットします (履歴を作成するだけです)。
  9. 上記の手順 (元のメッセージの 3 つの手順) を適用して、パッケージの名前を renametest から testrename に変更します。
  10. 専念。
  11. テスト走行。
  12. メッセージを再度変更してテストします。
  13. 専念。
  14. 最初に両方のメッセージが同時に変更されたバージョンにロールバックしてみてください。
  15. ここまでうまくいっていれば、よさそうですよね？

テストの結果:

  • ステップ 9 の注意:逆の順序で実行する必要がありました(Eclipse の名前を変更し、次に TortoiseSVN の名前を変更します)。そうしないと、TSVN が新しいフォルダー/パッケージを作成し、古いフォルダー/パッケージを削除するようにマークするため、複雑になっていました。 .svnフォルダーなどを失うのを防ぐために、その間に古いパッケージを別の場所に配置しない限り、Eclipseの名前を変更します。この方法をさらに進めるのは良い考えではありませんでした。(自分へのメモ: 再帰的なパッケージの名前変更のチェックボックスをオンにすることを忘れないでください!)
  • ステップ 14 に関する注意: うまくいきました! 以前のバージョンを見ることができます。コピー/移動で中断しないように指示するだけでOKです。名前を変更する前のバージョンに戻すと、パッケージ名は適切な名前には戻りませんが、おそらく再度リファクタリングするとうまくいくでしょう。
  • 終わりの注: 重要なステップを逆の順序で実行しなければならないことに驚きました。この最初のパッケージの名前変更試行の途中でこれを行うには、いくつかの TSVN と手動の変更をロールバックする必要があり、この手順の正確な結果の再現性に少し疑問を投げかけました. その有効性を確認するために、2 回目のテストを行う必要があります。要約すると、良さそうに見えますが、さらにテストする必要があります。
4

7 に答える 7

8

おそらくあなたの正確なニーズには実用的ではありませんが、TortoiseSVN には名前の変更に関する便利な機能があります。あなたはこれを行うことができます：

  1. IDE のリファクタリング機能を使用して名前を変更します。
  2. TortoiseSVN から「変更の確認」ダイアログを起動します。
  3. 名前が変更されたアイテムごとに、欠落している「source.java」アイテムとバージョン管理されていない「target.java」アイテムの 2 つのエントリが表示されます。両方を強調表示し、コンテキスト メニューから [移動の修復] を選択します。

移動の修復/名前の変更

于 2010-03-23T16:15:00.697 に答える
2

Eclipse に含まれるリファクタリング方法を使用している場合、履歴の保持が機能していませんか?

NetNeans では定期的にパッケージ名を変更し、基礎となる 'svn プラグイン' がコンテンツ (履歴を保存する) を新しいディレクトリに静かに移動します (その後、通常のリファクタリングが行われます)。

so: Subversion プラグインで履歴が保持されている場合、Eclipse 内から試しましたか? (たとえば、失敗を避けるために新しいチェックアウト コピーで)

少なくとも、NetBeans を使用してこの 1 回限りのタスクを実行できます...

于 2010-03-21T09:47:56.833 に答える
0

新しいパッケージに移動された (つまり、まだソース管理下にない) クラスをコミットすると、subclipse プラグインが "is already under version control" というエラー メッセージを表示し、このパッケージの親も new であることを発見しました。

これが発生したら、TortoiseSVN を使用して変更をコミットできます。その後、Eclipse でプロジェクトを更新するだけです。

親がすでにソース管理下にある新しいパッケージにクラスを移動した後、subclipse はこの変更を問題なくコミットできます。

于 2013-01-02T10:00:49.807 に答える
0

はい、うまくいきます。svn のコマンド ライン バージョンをインストールし、svn を実行するバッチ ファイルを作成できます。Eclipse を自動化するのはもう少し手間がかかりますが、Eclipse API に慣れていない限り、おそらく価値はありません。

すべての手順を正しく実行していることを確認するために、すべてを実行する前に 1 つのパッケージでテストしてください。

于 2010-03-21T05:02:06.393 に答える
0

これを行うことができ、それほど難しいことではありません - クリーンな SVN 履歴を取得するための最善の策は、2 つのステップで実行することです (1 つのコミットになる可能性があります) - ただし、良い結果を得るには、CLI クライアントを使用することをお勧めします。

  1. svn mv を使用してフォルダー/パッケージを移動します
  2. Eclipse に移動するか、CLI から grep を使用して、ファイル内のパッケージを新しい名前に一致するように修正します。

次に、変更セットとしてコミットすると、ファイル レベルの履歴が一致するはずです。

Maven またはパッケージング ツールを使用している場合は、このようなことを行う前にリリースを実行することをお勧めします。また、古い構造に戻る必要がある場合に備えて、この直前にタグをカットする価値があります。

于 2010-03-22T16:51:57.590 に答える