アプリを新しいリモート サーバーにすばやくデプロイするために、ブランチをローカル ディレクトリにエクスポートして圧縮し、新しいサーバーで解凍しました。
ここで、エクスポートされたコピー (リポジトリ内のブランチの正確なレプリカ) を作業コピーに変換します。これは可能ですか?
アプリを新しいリモート サーバーにすばやくデプロイするために、ブランチをローカル ディレクトリにエクスポートして圧縮し、新しいサーバーで解凍しました。
ここで、エクスポートされたコピー (リポジトリ内のブランチの正確なレプリカ) を作業コピーに変換します。これは可能ですか?
私の場合、次のワークフローを使用します。
live_from_xxyyzz
どこですか)xxyyzz
そうすることで、信頼できるタグがあるため、エクスポートされたバージョンを作業コピーに戻す必要はまったくありません。
一方、ライブバージョン(リモートサーバー上のバージョン)を取得して、作業ディレクトリにコピーするだけです。何かが違う場合は、それに気付くでしょう(ファイルの欠落や新しいファイルも同様です)。
編集:
エクスポートされたバージョンが作業コピーになる場合、svnの使用に少し問題があります。svn(現在).svn
には、チェックアウトされた作業コピーのフォルダーが必要です。これらの.svn
フォルダーには、バージョン情報が保持されます。エクスポートされたバージョン全体をバージョン管理下に置くには、これらのフォルダーを作成(および入力)する必要があります(つまり、実際の作業コピーからエクスポートされたバージョンにコピーします)。
Subversion 1.7以降、一元化されたメタデータストレージがあります。これは、すべてのバージョン管理関連ファイルが作業コピーごとに1つのフォルダーに保存されることを意味します(たとえば、Gitのように)。これで問題の解決が簡単になりますが、今のところ、.svn
上記のように作業コピーからフォルダーをコピーする以外に方法はありません(もちろん、実際にブランチをチェックアウトすることを除いて)。
エクスポートが単にブランチのコピーである場合、ブランチからチェックアウトしないのはなぜですか?
もちろん、すべての Subversion メタ ファイルが存在する限り、プロジェクトをリポジトリに接続し直すことができることに気付きました。サーバーに Subversion クライアントがあり、コマンド ラインで作業することを恐れない場合は、おそらく "svn status" を試して、リポジトリに接続できるかどうかを確認できます。