書き換えのバージョン管理の実践

製品（プロトタイプ）P_OLDを言語Xで開発し、現在は言語YでP_NEWとして最初から書き直しています。

P_NEWとP_OLDは同じ製品であるため：

P_NEWは古いP_OLDのブランチである必要がありますか、それとも独自のリポジトリである必要がありますか？

バージョン管理の観点からこのような大きな変更を処理する通常の方法は何ですか？

ほとんど確実に新しいリポジトリが必要です。

リポジトリの目的は次のとおりです。

• 履歴と変更を追跡して、簡単に比較できるようにします
• パッチファイルをメールで送信して作業ディレクトリに手動で適用するのではなく、ブランチとマージを管理する

プロジェクトを完全にゼロから書き直す場合、同じリポジトリに書き直しても意味がありません。古い言語で書かれたパッチを書き換えに適用することはできません。リポジトリを切り替えても、古いリポジトリの履歴は消えませんし、切り替えた場合、2つの言語がリポジトリで使用されているような奇妙な中間段階はありません。

言語を変更するときにリポジトリを保持することを検討する唯一の理由は、a）言語が非常に類似しているため、コードを変更せずに一方から他方にコピーアンドペーストできる場合、またはb）プロジェクトがある場合バージョン管理の機能コンテンツの大部分は、保持しているテンプレート言語のテンプレートのようなものであり、変更するコアの言語は、行ごとに別の言語に翻訳されます移行中はテンプレートを繰り返し処理する必要があります）。

私は常に自分自身で新しいリポジトリに書き直します。そうすれば、ビルド、テスト、展開をすべて独立して実行できます。

別の言語でプロジェクトを書き換えている場合、ビルド、テストの実行、展開などのタスクの類似性はほとんどありません。それらを独自のリポジトリに分離するだけで、苦痛を軽減できます。それから、古いシステムから新しいシステムへのユーザーとデータの移行をどのように管理するのかという苦痛だけを心配する必要があります。それはいつも楽しいことです。:)

システムが十分にモジュール化されており、リンクの互換性がある場合、単一のリポジトリとビルドの恩恵を受けるでしょう。たとえば、CシステムがC ++で書き換えられている場合、C ++コードは既存の機能を呼び出して、それを段階的に置き換えることができます。

ただし、この場合でも、関連する古いコードが必要に応じて取り込まれる新しいレポを開始することを主張する人もいるかもしれません。