アイテムをリビジョンに更新するか、リビジョンに戻す


161

TortoiseSVNでSubversionを使い始めました。ログを開いて古いリビジョンを右クリックすると、「アイテムをリビジョンに更新」と「このリビジョンに戻す」という2つのオプションが古いバージョンにロールバックされるように見えます。

古いバージョンを確認するだけで、実際にはリポジトリを変更しない場合に、古いリビジョンへの更新が使用されることを理解しています。元に戻すとは、実際に失敗して、リポジトリ内の最新のリビジョンを古いバージョンと同じにしたい場合です。

したがって、HEADリビジョンが100で、95に戻すと言います。作業コピーを95にリバースマージします。次に、リビジョン101を作成するリポジトリにその変更をコミットできますか?リビジョン95に更新する場合、どう違うのですか?それでも、最後のリビジョンからの変更を元に戻すだけではありませんか?古いリビジョンに復帰または更新した後、作業コピーの状態がどのように変化するかについて混乱しています。

回答:


205

リビジョンの更新は、作業コピーのファイルのみを選択したリビジョンに更新します。ただし、SVNが作業コピーが最新でないことを報告するため、このリビジョンでの作業を続けることはできません

このリビジョンに戻すと、選択したリビジョン(例では、リビジョン96、97、98、99、100)の後に行われた作業コピーのすべての変更が取り消されます。作業コピーは変更された状態になりました

両方scenarionsのファイルの内容は、あなたが持っているしかし、最初のケースでは、同じである未修正の作業コピーをして(あなたのworkingcopyがHEADを指していないとして、100をREV)変更をコミットすることはできません後者の場合では、あなたが持っている修正頭を指して作業コピーをし、引き続き作業してコミットできます


1
では、リビジョンに更新して、作業コピーのデータがなくなったとしましょう。ファイルの変更を妨げるものは何もありません。ファイルの1つを変更してコミットしようとするとどうなりますか?Subversionが競合を確認し、サブミットする前にリポジトリ内の最新バージョンを変更した作業用コピーにマージすることを強制すると思います。
エリック

5
HEADよりも古いBASE-Revisionでアイテムをコミットしようとすると、「コミットに失敗しました:作業コピーがおそらく古くなっています」
Peter Parker、

ローカルの変更(コミットされていない変更)をどのようupdate torevert to/from処理しますか?
BaltoStar 2017年

どちらの方法でもローカル変更はそのまま保持されますが、ローカル変更はどちらの場合も競合を引き起こす可能性があり、元に戻す場合はロールバックからの変更が他のすべてのユーザーのローカル変更と混合されます。したがって、少なくとも変更のパッチを保存するか、ブランチにコミットします。
Peter Parker

31

両方のシナリオで作業コピーの状態がどのように異なるかを理解するには、BASEリビジョンの概念を理解する必要があります。

ベース

作業コピー内のアイテムのリビジョン番号。アイテムがローカルで変更されている場合、これは、ローカルで変更されていないアイテムの表示方法を指します。

作業コピーには、このBASEリビジョンの各ファイル(.svnフォルダーに非表示)のスナップショットが含まれています。これは、リポジトリから最後に取得されたときと同じです。これは、作業コピーが2倍のスペースを取る理由と、ネットワーク接続なしでローカルの変更を調べたり、元に戻したりすることが可能な理由を説明しています。

アイテムをリビジョンに更新すると、このベースリビジョンが変更され、BASEが古くなります。ローカルの変更をコミットしようとすると、SVNは、BASEがリポジトリのHEADと一致しないことに気づきます。これを修正するために更新(および場合によってはマージ)を行うまで、コミットは拒否されます。

リビジョンに戻すと BASEは変わりません。概念的には、以前のリビジョンと一致するようにファイルを手動で編集するのとほとんど同じです。


受け入れられた答えから「両方のシナリオのファイル内容は同じです」。なぜわざわざ?この回答は、最終的な違いを説明し、「更新」対「復帰」がコミットを試行するときに異なる動作を引き起こす理由を説明します。
radarbob

ローカルの変更(コミットされていない変更)をどのようupdate torevert to/from処理しますか?
BaltoStar 2017年

5

作業コピー内のファイルはその後まったく同じに見えるかもしれませんが、それらはまだ非常に異なるアクションです-リポジトリは完全に異なる状態にあり、元のリビジョンに「更新」するよりも、元に戻した後で使用できるオプションが異なります。 。

簡単に言うと、「更新先」は作業コピーにのみ影響しますが、「逆マージとコミット」はリポジトリに影響します。

古いリビジョンに「更新」しても、リポジトリは変更されていません。例では、HEADリビジョンは100のままです。作業コピーをいじるだけなので、何もコミットする必要はありません。作業コピーに変更を加えてコミットしようとすると、作業コピーが古くなっていることが通知され、コミットする前に更新する必要があります。同じリポジトリで作業している他の誰かが「更新」を実行した場合、または2番目の作業コピーをチェックアウトした場合は、r100になります。

ただし、古いリビジョンに「リバースマージ」する場合、作業コピーはまだHEADに基づいています(最新であることが前提です)。ただし、不要な変更に取って代わる新しいリビジョンを作成しています。リポジトリを変更しているので、これらの変更をコミットする必要があります。完了すると、HEADに基づく更新または新しい作業コピーには、コミットした内容でr101が表示されます。


5

作業コピーを選択したリビジョンに更新します。作業コピーに過去の時刻を反映させたい場合、またはリポジトリへのコミットがさらにあり、作業コピーを一度に1つずつ更新したい場合に便利です。1つのファイルだけでなく、作業コピーのディレクトリ全体を更新することをお勧めします。そうしないと、作業コピーに矛盾が生じる可能性があります。これは、特定のリビジョンの目的をテストするために使用されます。テストが完了したら、このコマンドを使用して別のリビジョンをテストするか、SVN Updateを使用してHEADを取得できます。

以前の変更を永久に取り消す場合は、代わりに「このリビジョン戻す」を使用してください。

-TSVNヘルプドキュメントから

作業コピーを以前のリビジョンに更新する場合、これは自分の作業コピーにのみ影響します。変更を加えてコミットした後、失敗します。TSVNは、WCを最初に最新リビジョンに更新するよう警告します。リビジョンに、あなたはリポジトリにコミットすることができます。誰もが彼らが更新をした後、リビジョンに戻ります。


2

亀のリファレンスからのテキスト:

アイテムをリビジョンに 更新作業コピーを選択したリビジョンに更新します。作業コピーに過去の時刻を反映させたい場合、またはリポジトリへのコミットがさらにあり、作業コピーを一度に1つずつ更新したい場合に便利です。1つのファイルだけでなく、作業コピーのディレクトリ全体を更新することをお勧めします。そうしないと、作業コピーに矛盾が生じる可能性があります。

以前の変更を永久に取り消す場合は、代わりに「このリビジョンに戻す」を使用してください。

このリビジョンに 戻す以前のリビジョンに戻します。いくつかの変更を加えた後、リビジョンNの状態に戻りたい場合は、これが必要なコマンドです。変更は作業コピーで元に戻されるため、変更をコミットするまで、この操作はリポジトリに影響を与えません。これにより、選択したリビジョン以降に行われたすべての変更が取り消され、ファイル/フォルダーが以前のバージョンに置き換えられます。

作業コピーが変更されていない状態の場合、このアクションを実行すると、作業コピーは変更されたものとして表示されます。すでにローカルの変更がある場合、このコマンドは元に戻す変更を作業コピーにマージします。

内部で起こっていることは、Subversionは選択されたリビジョンの後に行われたすべての変更のリバースマージを実行し、それらの以前のコミットの効果を取り消すことです。

このアクションを実行した後で、元に戻す操作を元に戻し、作業コピーを変更前の状態に戻す場合は、WindowsエクスプローラーからTortoiseSVN→元に戻すを使用する必要があります。これにより、このリバースマージアクションによって行われたローカル変更が破棄されます。

以前のリビジョンでのファイルまたはフォルダーの外観を確認したいだけの場合は、代わりに[リビジョンを更新]または[リビジョンを別名で保存...]を使用します。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.