TortoiseSVN Logo

よくある質問

目次

インストールとアップグレード

広告

オーバーレイアイコン

一般的な質問

どうすれば...

エラーメッセージ

インストールとアップグレード

TortoiseSVN をアップグレードする際、既存のバージョンを最初にアンインストールする必要がありますか？

いいえ。古いバージョンに新しいバージョンを上書きインストールするだけで済みます。インストーラーが古いバージョンを自動的にアンインストールします。ただし、インストーラーが終了したらコンピューターを再起動する必要があります！または、少なくともログオフして再度ログオンする必要があります。

TortoiseSVN をインストールするには管理者権限が必要ですか？

はい、TortoiseSVN をインストールするには管理者権限が必要です。または、少なくとも管理者権限付きでインストールする権限が必要です。

ただし、TortoiseSVN がインストールされた後は、管理者権限なしで使用できます。

TortoiseSVN を使用する前に Subversion をインストールする必要がありますか？

いいえ。TortoiseSVN には、リポジトリにアクセスするために必要なものがすべて付属しています。サーバーをセットアップしたい場合にのみ、Subversion パッケージが必要になります。

TortoiseSVN をアンインストールする方法は？

Windows コントロールパネルの [プログラムの追加と削除] からアンインストールするだけです。これは、リポジトリやワーキングコピーにはまったく影響しません。

私のマシンでは MSI インストールが無効になっています。.exe インストーラーはありますか？

exe インストールファイルは役に立ちません。マシンで MSI インストールが本当に無効になっている場合、管理者権限もありません。そして、TortoiseSVN をインストールするにはそれらが必要になります（シェル拡張機能にはインストールするための管理者権限が必要です）。ただし、最初に MSI インストールが本当に無効になっていることを確認してください。それはドメイン管理者が無効にした場合にのみ可能です。

なぜ exe やインストーラーなしではなく MSI を使用しているのですか？

MSI を他のインストーラーの代わりにインストーラーとして使用する理由はいくつかあります

  • オープンです。Orca のような MSI ツールを使用することで、誰もが私たちの行っていることを見ることができます。
  • 必要に応じて、既存の MSI を特別なニーズに合わせて簡単に調整できます。MSI を手動で編集できるツールがあります。exe インストーラーではそれはできません。
  • 管理者としてだけでなく、SYSTEM 権限で実行されます。これは、TortoiseSVN がユーザーアカウントがアクセスできないレジストリキーを作成および変更する必要があるシェル拡張機能であるため重要です（これは、UAC が有効になっている Vista で特に重要です）。
  • MSI を GPO 経由でドメイン内の複数のコンピューター/ユーザーに簡単に配布できます。他のすべてのインストーラーでは、ドメイン管理者が最初に MSI 内にそのインストーラーを「ラップ」してそれを行う必要があります。
  • MSI は、Windows アプリケーションをインストールするための標準的かつ推奨される方法です。Microsoft から「Certified for Vista」ロゴを取得するには、現在必須です。
  • MSI ファイルを作成するための優れたオープンソースツールがあります：WiX を使用しています。
  • MSI は、インストールされているモジュールの参照カウントを処理し、いわゆる dll hell を防ぎます。
  • シェルに TortoiseSVN を登録する必要があるため、インストーラーが必要です。実行するための単純な exe は機能しません。

インストーラーがエラーメッセージで中止します

インストールが成功しない理由はいくつかあります

  • 「このインストールパッケージはこのプロセッサタイプではサポートされていません。製品ベンダーにお問い合わせください。」 これは、通常の 32 ビットオペレーティングシステムに 64 ビットバージョンの TortoiseSVN をインストールしようとしていることを意味します。OS 用の正しい MSI ファイルをダウンロードして使用する必要があります。通常の 32 ビット OS の場合、MSI ファイルに x64 が含まれていないことを確認してください。
  • 「TortoiseSVN をインストールする前にインストーラーが中断されました。再試行するにはインストーラーを再起動する必要があります。」 次に、ユーザー SYSTEM には、インストーラー MSI が配置されているフォルダーの読み取り/実行権限がありません。MSI ファイルを別の場所に移動するか、ユーザー SYSTEM に読み取りおよび実行権限を付与してください。
  • 「Windows インストーラーサービスにアクセスできませんでした。」 これは、Windows をセーフモードで実行している場合、または Windows インストーラーが正しくインストールされていない場合に発生する可能性があります。基本的に、MSI が保存されているフォルダーが暗号化または圧縮されていないことを確認してください
  • 「システムは指定されたファイルのデバイスを開けません」、通常は 「インストーラーがこのパッケージのインストール中に予期しないエラーを検出しました。これは、このパッケージに問題があることを示している可能性があります。エラーコードは 2755 です。」 が続きます。これは、次の場合に発生する可能性があります
    • インストールに Temp ディレクトリへのアクセス権がない場合、またはマシンのデフォルトの Temp ディレクトリがクリーンでない場合、またはセットアップを実行するのに十分なスペースがない場合。
    • インストールが、マップされたネットワークドライブ経由でターミナルサーバー上で実行されている場合。
    • インストールが、Windows NT システム環境のインストーラーディレクトリを作成または書き込みできない場合。
    • temp フォルダーおよび/または MSI ファイルが暗号化/圧縮されている場合
    この問題を解決するには、temp フォルダーをクリアし、インストーラー MSI ファイルをユーザー SYSTEM がフルアクセス権を持つローカルハードドライブに移動します。
  • 「このインストールパッケージは、Windows インストーラーサービスでインストールできません。Windows インストーラーサービスの新しいバージョンを含む Windows サービスパックをインストールする必要があります。」 少なくとも MSI インストーラーのバージョン 3 が必要です。

インストール後、TortoiseSVN が表示されず、コンテキストメニューが利用できません

XP または Vista 64 ビットを使用している場合は、TortoiseSVN の x64 バージョンをインストールしていることを確認してください。これらの OS バージョンのエクスプローラーは 64 ビットアプリケーションであるため、32 ビットバージョンの TortoiseSVN をロードできません。

ただし、これらの OS バージョンに 32 ビットバージョンの TortoiseSVN をインストールしたままにすることもできます。それらのアプリケーションの 32 ビットアプリケーションのファイルを開く/保存するダイアログに表示されます。

インストール後、ファイルに TortoiseSVN のコンテキストメニューが表示されません

この問題は、レジストリのアクセス許可の設定が原因である可能性があります。以下を試してください

  1. regedit を使用してレジストリエディターに移動します。
  2. HKEY_CLASSES_ROOT/*/​shellex/ContextMenuH​andlers/TortoiseSVN をクリックします
  3. アクセスが拒否されたことを示すエラーメッセージボックスが表示されることを確認します。
  4. 上記で言及したキーを右クリックし、「アクセス許可」に進みます...
  5. アクセス許可ダイアログで、「詳細設定」をクリックします
  6. 「所有者」タブをクリックし、アカウントをクリックして「適用」をクリックします
  7. ダイアログを [OK] し、「追加...」をクリックします
  8. テキストエリアにアカウント名を入力し、「OK」をクリックします
  9. アクセス許可ダイアログを [OK] します。
  10. HKEY_CLASSES_ROOT/*/​shellex/ContextMenuH​andlers/TortoiseSVN をクリックします
  11. エラーメッセージボックスがないことを確認します。

レジストリを編集するのに十分なアクセス許可がない問題がある場合は、SysInternals PsTools Suite をダウンロードし、次のコマンドで regedit を起動することで回避できます

PsExec.exe -i -d -s c:\windows\regedit.exe

オーバーレイアイコン

TortoiseSVN をアップグレード後、すべてのアイコンオーバーレイが消えてしまいました

これは、一部のアップグレードで発生する既知の問題であり、特に 1.6.8 で報告されています。これがあなたに起こった場合は、修復インストール（および再起動）を試してください。

それでもうまくいかない場合は、これらの他の FAQ エントリを試してください

アイコンオーバーレイが表示されないのはなぜですか？

  • インストール後、PC を再起動しましたか？まだの場合は、今すぐ再起動してください。TortoiseSVN は Windows エクスプローラーシェル拡張機能であり、エクスプローラーと一緒にロードされます。
  • TSVN の設定に移動し、少なくとも固定ドライブのアイコンオーバーレイをアクティブにします。インストーラーはこれを現在のユーザーに対して自動的に行いますが（他のユーザーに対しては実行できません...）、TSVN をインストールしたユーザーとは異なるユーザーとして使用しているため、これを手動で設定する必要があります。

オーバーレイアイコンは表示されますが、すべてではありません！

これらのアイコンの一部がシステムで使用されていない場合があります。これは、Windows で許可されるオーバーレイの数が 15 に制限されているためです。Windows はそれらのうち 4 つを使用し、残りの 11 は他のアプリケーションで使用できます。また、OneDrive がインストールされている場合、さらに 5 つのスロットを使用します。次に、別のクラウドドライブツールがインストールされている場合、これらのスロットが使い果たされる可能性があります。TortoiseSVN は「Good Citizen (TM)」? であることを目指しており、他のアプリにチャンスを与えるためにオーバーレイの使用を制限しています。

  • 通常、変更済み、および競合は常にロードされ、表示されます（可能な場合！）。
  • 削除済みは可能な場合はロードされますが、十分なスロットがない場合は変更済みにフォールバックします。
  • 読み取り専用は可能な場合はロードされますが、十分なスロットがない場合は通常にフォールバックします。
  • ロック済みは、すでにロードされているオーバーレイが 13 未満の場合にのみロードされます。十分なスロットがない場合は通常にフォールバックします。
  • 追加済みは、すでにロードされているオーバーレイが 14 未満の場合にのみロードされます。十分なスロットがない場合は変更済みにフォールバックします。

regedit を使用して HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers を確認することで、他のアプリがオーバーレイを使用しているかどうかを確認できます

オーバーレイを使用することがわかっている他のアプリ
  • Windows 自体。Vista と Win7 は XP よりも多く使用します。
  • OneDrive
  • GDrive
  • Mega
  • Dropbox
  • その他多数

インストールされているオーバーレイハンドラーが多すぎる場合、TortoiseSVN がオーバーレイを表示しない場合は、インストールされているハンドラーの一部をレジストリから削除してみてください。ただし、レジストリを編集するときは注意してください！

アイコンがローカルドライブでのみ表示され、ネットワークドライブでは表示されないのはなぜですか？

[設定] -> [外観] -> [アイコンオーバーレイ] に移動し、オーバーレイアイコンを表示するドライブタイプをチェックします。ネットワークドライブのオーバーレイを有効にすると、TortoiseSVN だけでなくシステム全体が遅くなることに注意してください。

SUBST ドライブのオーバーレイアイコンが乱れているのはなぜですか？

ワーキングコピーが SUBST ドライブにある場合、アイコンが混同される可能性があります。

問題が発生するのは、キャッシュが 2 つの「異なる」場所のステータスを同時にフェッチしようとするためですが、これらの場所は実際には同じであるため、同じワーキングコピーに対して 2 つのステータスフェッチが同時に行われます。

これを解決する簡単な方法があります：オーバーレイを表示しないように元のパスを除外するだけです（[設定]->[アイコンオーバーレイ]->[パスを除外]）。

たとえば、\\station\folder\wc を g: にマップした場合、\\station\folder\wc* を除外パターンとして入力します。

オーバーレイを機能させるもう 1 つの方法は、「ステータスキャッシュ」設定を「デフォルト」から「シェル」に変更することです。

オーバーレイが間違ったステータスを表示するのはなぜですか？

オーバーレイがファイルやフォルダーの実際のステータスを反映していない場合があります。通常、F5 キーを押すだけでオーバーレイが正しく表示されます（キャッシュがステータスを再度フェッチするまで数秒待つ必要がある場合があります）。

エクスプローラーの左側のツリービューはまったく別の話です。何度 F5 キーを押してもオーバーレイは更新されません。それはエクスプローラーの問題であり、TortoiseSVN の手の届かないところにあります。

簡単な説明：ツリービューは常に、ネットワークドライブや他の名前空間拡張機能を含むエクスプローラーツリー全体を表示します。これらは非常に遅くなる可能性があるため（例：遅いネットワークドライブ）、エクスプローラーツリーは常に更新されたオーバーレイをオーバーレイ拡張機能に要求しません。フォルダーが変更されたことをエクスプローラーに通知し、それに応じてオーバーレイを更新する必要がある場合でも、そうではありません。最初にフォルダーが本当に変更されたかどうかを自分で確認し、フォルダーが本当に変更されたと判断した場合にのみオーバーレイを更新します。

さて、フォルダーの Subversion ステータスはフォルダー自体とは何の関係もないため、フォルダー自体は実際には変更されません（.svn フォルダー内のファイルのみですが、フォルダー自体ではありません）、したがってエクスプローラーはオーバーレイを更新しません。

エクスプローラーに左側のツリービューでもオーバーレイを更新させるためのいくつかのトリックと回避策がありますが、それらはトリックと回避策であり、明らかに常に機能するとは限りません。

通常は機能するトリックが 1 つありますが、それは遅く、TortoiseSVN はそのトリックをオンザフライで使用できません。システムを大幅に遅くするだけです。ただし、ワーキングコピーのルートで 'cleanup' コマンドを実行することで、そのトリックを手動でトリガーできます。cleanup コマンドが完了したら、ツリービューがオーバーレイアイコンを更新するまで数秒待つ必要があります。

オーバーレイアイコンが時々ランダムなグラフィックに変わるのはなぜですか？

Windows アイコンキャッシュはかなりバギーな生き物です。次のいずれかの方法でこれを解決できます

  • Microsoft の TweakUI をインストールし、アイコンを再構築するオプションを実行します。
  • または、アイコンキャッシュサイズを増やします。HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer に移動し、Max Cached Icons という名前の新しい文字列値を追加します。デフォルト値は 500 です。2048 に増やしてみてください。
  • または、Windows ディレクトリにある ShellIconCache というファイルを削除します。そして、再起動します。
  • TortoiseSVN 1.3.0 以降では、コマンドラインから TortoiseProc.exe /command:rebuildiconcache のように TortoiseProc を呼び出すことで、アイコンキャッシュを再構築することもできます

「更新あり」または「他のユーザーによってロックされています」のオーバーレイがないのはなぜですか？

そのようなオーバーレイを表示するには、TortoiseSVN はオーバーレイが表示されるたびにリポジトリに接続する必要があります。それはエクスプローラーを非常に遅くするでしょう。サーバーは応答に数秒、場合によっては数分かかることがよくあります。バージョン管理されたフォルダーを開くたびにそれが起こる間、エクスプローラーをハングアップさせたいですか？

TortoiseSVN の基本的な設計機能は、コンテキストメニュー項目の 1 つによって明示的に要求された場合を除き、リポジトリに決して接続しないことです。その制限があっても、高速な応答を維持するのは依然として大変な作業です。

ワーキングコピーでファイルをロックしているユーザーや、更新が必要なファイルを確認する場合は、[変更の確認] ダイアログを使用し、[リポジトリを確認] ボタンをクリックします。

オーバーレイアイコン

ファイルを右クリックすると CPU 使用率が 100% になります。

ファイルを右クリックするたびに、CPU 使用率が 100% になります（右クリックメニューが表示されている間）。メニューから何かを選択すると、CPU 使用率が正常に戻ります。「何もないところ」を右クリックすると、CPU は正常です。何が起こっているのですか？

XP には、特定の構成でコンテキストメニューにアクセスすると CPU 使用率が 100% に急上昇する既知のバグが含まれています。このバグにより、ファイルコピー操作が停止し、ネットワーク接続が遅くなり、ストリーミングメディア（オーディオ、ビデオなど）が歪んでしまいます。このバグを回避するには、次の手順を実行して GUI のトランジション効果を無効にする必要があります

  1. コントロールパネルの [画面] アプレットを起動します。
  2. [デザイン] タブを選択します。
  3. [効果] をクリックし、[メニューとツールチップに次のトランジション効果を使用する] チェックボックスをオフにします。
  4. [OK] をクリックして、すべてのダイアログボックスを閉じます。

多くの場合機能する別の解決策は、コンテキストメニューを表示する前にファイルまたはフォルダーを左クリックすることです。

ネットワークディレクトリにローカルリポジトリを作成できますか？

ネットワーク共有上のリポジトリを使用できますが、ローカルハードドライブを使用する場合と同様に、シングルユーザーとしてのみ使用できます。次の FAQ 項目では、この方法でリポジトリを共有することが Bad Idea (TM) である理由について説明します。ネットワーク共有にリポジトリを保持する本当に差し迫った理由がない限り、一般的にそうしないことをお勧めします。

ネットワーク共有上のリポジトリに本当にアクセスする必要がある場合は、次のいずれかを実行する必要があります

  1. 次の構文を使用してドライブマッピングを使用します
    //server/shared を S にマップします
    file:///S:/repos （ドライブ文字の前に 3 つの先頭のスラッシュ）
  2. 次の構文を使用して UNC パスを直接指定します
    Subversion >= 1.2
    file://server/shared/repos （2 つの先頭のスラッシュ）
    Subversion < 1.2 （奇妙な構文ですが、ご存知のとおり）
    file://///server/shared/repos （5 つの先頭のスラッシュ）
    file:///\server/shared/repos （3 つのスラッシュ + バックスラッシュ）

ただし、警告しなかったとは言わないでください...

サーバーをセットアップする代わりに、ネットワーク共有にリポジトリを保持できますか？

複数のコンピューターがリポジトリにアクセスする必要がある場合、理論的にはネットワーク共有にリポジトリを作成し、file:// プロトコルを使用してアクセスできます。実際には、これには 4 つの非常に正当な理由から推奨されません

  1. すべてのユーザーに直接書き込みアクセス権を付与しているため、誤ってリポジトリファイルシステムを削除または破損する可能性があります。
  2. すべてのネットワークファイル共有プロトコルが Subversion が必要とするロックをサポートしているわけではありません。いつの日か、リポジトリが微妙に破損していることに気付くでしょう。
  3. アクセス許可を適切な方法で設定する必要があります。SAMBA はこの点で特に困難です。
  4. ある人がリポジトリ形式をアップグレードする新しいバージョンのクライアントをインストールすると、他のすべての人は新しいクライアントバージョンにアップグレードするまでリポジトリにアクセスできなくなります。

最良の方法は、実際的なサーバープロセス（Apache や svnserve など）をセットアップし、サーバーがアクセスできるローカルファイルシステムにリポジトリを保存し、リポジトリサーバーをネットワーク経由で利用できるようにすることです。それはあなたが思うよりも簡単です。Subversion Book の第 6 章「サーバー構成」では、このプロセスについて詳しく説明しています。

ワーキングコピーをネットワーク共有に保存できますか？

これはネットワーク共有によって異なります。しかし、私たちは本当に、本当にこれをしないように強く促します！Windows サーバーを使用してこれらのネットワーク共有を使用している場合でも、fcntl() ファイルロックは完全には信頼できません。そして、Samba ベースの共有の場合、すべてが当てはまりません。つまり、破損したワーキングコピーを取得し、データを失うことになります！今日ではないかもしれませんが、明日ではないかもしれませんが、いつか必ず。

ネットワーク共有にワーキングコピーを保存する必要がある場合は、SQLite プロジェクトの対応する FAQ エントリ をよく読んでください。

同じワーキングコピーで異なる Subversion クライアントを使用できますか？

はい、いつでもクライアントを別のクライアントに変更できます。クライアントは、ワーキングコピーと、ワーキングコピーとリポジトリ間の相互作用のみを制御します。異なるクライアントで使用されるワーキングコピー内のメタデータは同一です。

ただし、すべてのクライアントが同じバージョンの Subversion ライブラリを使用している場合にのみ、異なるクライアントを使用できます。TortoiseSVN が使用する Subversion ライブラリのバージョンは、インストーラーのファイル名に示されています。他のクライアントにも同様の表示があります。これらのバージョンの最初の 2 桁が一致していることを確認する必要があります。たとえば、Subversion 1.6.x を使用するすべてのクライアントは一緒に使用できます（「x」は、この番号が互換性に関係がないことを示します）。

また、すべてのクライアントが同じ OS 用に構築されていることを確認する必要があります。クライアントの互換性は、特定の OS タイプでのみ保証されており、メタデータ表現が異なる場合があります。同じワーキングコピーでネイティブ Windows クライアントと Cygwin クライアントを使用しないでください。また、ネットワーク経由でワーキングコピーを共有する場合は、同じワーキングコピーで Linux クライアントと Windows クライアントを使用しないでください。

TortoiseSVN はテキストファイルの改行コードをその場で変換できますか？

svn:eol-style プロパティに関する subversion book を こちら で確認してください。そのプロパティをたとえば「native」に設定すると、ファイルは Linux では LF 改行コードになりますが、Windows では CRLF 改行コードになります。TortoiseSVN でこれらのプロパティを設定する方法については、ドキュメント こちら をお読みください。

ディレクトリのプロパティリストにある競合が何であるかを知るにはどうすればよいですか？

プロパティが競合しているフォルダー内に、dir_conflicts.prej というファイルがあります。テキストエディターでそのファイルを開くと、競合しているプロパティが表示されます。保持したいものを選択し、競合しているプロパティをそれで上書きします。

誤ってファイルを削除しました。どうすれば元に戻せますか？

まだ変更をコミットしていない場合は、ファイルまたはディレクトリを削除した親フォルダーで revert を実行できます。

削除したファイルをすでにコミットしている場合は、リポジトリブラウザを使用して、ファイルがまだ存在していたリビジョンに変更し、コンテキストメニューから Copy to... コマンドを使用できます。ターゲットとしてワーキングコピーへのパスを入力すると、削除したファイルがリポジトリからワーキングコピーにコピーされます。

この手法を使用して、削除されたディレクトリを復元することもできます。

このトリックを使用してファイル/フォルダーを復元した後、ログダイアログにそのファイルの履歴が表示されない場合でも、心配しないでください。履歴はまだそこにあります。SVN でファイルをコピーすると、その履歴もコピーされます。ただし、TSVN の ShowLog のデフォルト設定は「コピーで停止」です。つまり、履歴を見ると、ブランチポイントまでしかさかのぼりません。これの理由は、プロジェクトの実際のブランチを見ている場合、ほとんどの場合、そのブランチの履歴のみを表示したいからです。ShowLog で全体の履歴を表示するには、「コピーで停止」チェックボックスをオフにし、「すべて取得」をクリックする必要があります。

リンクを右クリックすると、複数の TortoiseSVN コンテキストメニューエントリが表示されます！

これは仕様です。1 つのエントリはリンク自体（.lnk ファイル）用、もう 1 つはリンクが指すターゲット用です。このようにして、リンクはバージョン管理され、同時にターゲットでの操作を許可することでリンクが期待どおりに機能します。実際、ファイルメニューに最大 3 つのエントリを含めることができます（コンテキストメニューには 2 つのみが表示されます）。

Visual Source Safe のように「共有ファイル」を使用することは可能ですか？

はい、ただし、いくつかの制限があります。「ファイル外部参照」を使用して、ワーキングコピーと同じリポジトリの別の部分から単一のファイルを取得できますが、外部リポジトリからは取得できません。フォルダーを共有することもできます。これらは任意のリポジトリからのものでもかまいません。外部定義の章を Subversion Book で参照してください。

サーバーなしで TortoiseSVN を使用することは可能ですか？

はい、そうです。file:// プロトコルを使用して、ローカルでリポジトリにアクセスできます。ただし、これはテストのみに強くお勧めします。詳細な説明については、この FAQ エントリ を参照してください。

TortoiseProc を使用する際に、ユーザー名とパスワードを送信する方法はありますか？

TortoiseSVN は GUI クライアントであるため、必要な場合はユーザー名とパスワードを求められます。ユーザーの操作なしに（つまり、必要に応じてユーザー名とパスワードを入力せずに）リポジトリへのアクセスを自動化する場合は、コマンドラインクライアントを使用してください。

リビジョングラフはどのように機能しますか？

リビジョングラフは少し特殊で、TortoiseSVN にある他の機能とは異なります。ファイルまたはフォルダーがコピー、移動、ブランチ、またはタグ付けされたすべてのリビジョンを含む、履歴を通じてファイルまたはフォルダーのグラフを表示します。

リポジトリルートのログを取得する必要がある理由、または HEAD リビジョンから最初のリビジョンまで完全なログを取得する必要がある理由について質問されることがよくあります。

明確にするために、これは私たちが怠惰なプログラマーであるためではなく、本当に必要なのです。

リビジョングラフは、選択した項目がコピーされたすべてのリビジョンを見つけることによって、選択したファイルまたはフォルダーの履歴を表示します。そして、グラフは利用可能な情報を使用してそれを行う必要があります。

選択したファイルまたはフォルダーのログメッセージを見ると、ログダイアログの下部ペインに、選択したリビジョンのすべての影響を受けるパスが表示されます。その情報は、リビジョングラフに使用するものです。また、たとえば /trunk のログを表示するだけの場合、タグまたはブランチで発生したリビジョンのログダイアログにはエントリが表示されないことにも気づくでしょう。そのログでは、/trunk 自体にタグ付けまたはブランチ付けしたエントリさえ表示されません。--> それが、リポジトリルートのログをフェッチする必要がある理由です。リポジトリルートのログのみが、パスがいつ、どこにコピー/ブランチ/タグ付け/移動されたかなど、必要なすべての情報を提供します。

特定範囲のログのみをフェッチし、すべてのリビジョンをフェッチしない場合、（/trunk の例をまだ使用して）トランクがブランチまたはタグ付けされたリビジョンを見逃す可能性があります。また、これらのブランチとタグに変更がある場合や、リビジョン範囲にまだ存在している場合でも、グラフはこれらのブランチ/タグが /trunk から作成されたものであり、他のパスから作成されたものではないことを認識できません。つまり、グラフは不完全であるだけでなく、間違っていることになります。

そして、いいえ。私たちはそれを決して変更しません。なぜなら、時々しか正しくないグラフほど悪いものはないからです。それがいつ、そして正しいかどうかを知ることは決してないでしょう。つまり、それは役に立たないものよりも悪いでしょう。

svn+ssh 経由で変更をコミットすると、ログに「author」が表示されないのはなぜですか？

SSH は認証プロセスを完全に処理するため、Subversion はコミットを実行する author を認識しません。したがって、Subversion に author を伝えるには、URL 自体で author を指定する必要があります。例：svn+ssh://[email protected]。ワーキングコピーをチェックアウトするときにそれを行う必要があります。

TortoiseSVN がファイルが変更されたことを認識しないのはなぜですか？

ファイルを変更したが、TortoiseSVN がファイルが変更されたことを認識しない場合は、最初にファイルがワーキングコピーにあるものと本当に異なるかどうかを確認してください。

ファイルに変更があり、コミットダイアログで変更済みとしてまだ表示されないことが確実な場合は、次のことを確認してください

  • ファイルの「最終更新日」が変更されている（一部のツール、たとえば 16 進数エディターは、その時間をリセットすることを好む）
  • svn:eol-style プロパティが設定されていて、変更が改行のみの場合、Subversion にとっては変更されていないため、ファイルは変更済みとして表示されません

Subversion は、次のアプローチでファイルが変更されたかどうかを判断します

  1. 「最終更新日」および/またはファイルサイズが変更されましたか？
  2. そうでない場合：ファイルは変更されていません
  3. はいの場合：ファイルの内容を BASE ファイルと比較します
  4. 異なる最初のバイトで停止し、ファイルを変更済みとしてマークします
  5. BASE に関してバイトが異ならない場合は、ファイルを未変更としてマークします

ファイルを削除すると消えてしまいますが、コミットするにはどうすればよいですか？

簡単です。ディレクトリ全体をコミットします！ファイル​​の横のエクスプローラーウィンドウで右クリックし、コミットを選択します。コミットダイアログには、すべての変更と、追加または削除されたファイルが表示されます。

SAMBA 共有上のワーキングコピーでのアクセス許可の問題。

TortoiseSVN 1.5.x 以降にアップグレードした後、ワーキングコピーが SAMBA 共有に保存されている場合、ほとんどの Subversion コマンドで多数の「アクセスが拒否されました」エラーが発生します。

一部のユーザーは、SAMBA を最新バージョンにアップグレードすると問題がなくなったと報告しています。それが役に立たない場合、またはアップグレードできない場合は、SAMBA 構成ファイルで読み取り専用ファイルの削除を許可してください

[global]
delete readonly = yes
古いバージョンの場合は、次を試してください
[global]
create mask = 0644
force create mode = 0600
security mask = 0555
force security mode = 0600

入手した情報によると、主な問題は SAMBA 3.2.3 で修正されているようです。svn:needs-lock プロパティを持つファイルを読み取り専用にするという追加の問題があります。これは SAMBA 3.2.6 または 3.3.0 で修正されたと報告されています。

エクスプローラーとファイル/開くダイアログでの閲覧が非常に遅いです。

解決されていないネットワークドライブをマップしている場合、ドライブにアクセスできない、またはログインしていないなどの理由で、Windows がドライブへのアクセスを試行している間、ファイルブラウジングが応答しなくなることがあります。ドライブのマッピングを解除するか、アクセスできることを確認してください。

リポジトリブラウザから開始されたダイアログでは、bugtraq: プロパティが機能しません。

これは仕様です。リポジトリブラウザはプロパティを読み取りません。リモートで実行すると非常に遅い操作になるためです。ローカルのワーキングコピーから読み取る場合にのみ十分に高速です。

TortoiseSVN がこれらのプロパティをリポジトリから直接読み取ると、取得に数秒 (数分かかることもあります!) かかる可能性があります。

ログを表示するとクラッシュすることがよくあります。

ログキャッシュは、すべてのリポジトリが異なる UUID を持っていることに依存しています。理由と対策の詳細な説明はこちらをご覧ください: https://tortoisesvn.dokyumento.jp/logcacheuuids.html。

多くの Subversion ホスティング企業が、顧客のために新しいリポジトリを作成せずに、単にテンプレートリポジトリをコピーするという間違いを犯したことを認識しています。そのようなホスターを使用している場合は、彼らにこの問題を修正するように伝えてください。

ワーキングコピーを更新すると、新しいファイルが追加されません！

TortoiseSVN 1.6.0 から 1.6.1 の間で、追加されたフォルダは "このアイテムのみ" の深さで追加されました。これにより、ワーキングコピーのその部分のいわゆる「スパースチェックアウト」が発生しました。

今後のこのような問題を避けるために、TortoiseSVN の最新バージョンにアップデートしてください。

スパースワーキングコピーを修正するには、「アップデート」の代わりに、TortoiseSVN サブメニュー (エクスプローラーで右クリック) から「リビジョンまでアップデート...」コマンドを使用し、「アップデートの深さ」コンボボックスを「完全再帰」に変更します。

問題/バグ X が rXXX で修正されたと聞きましたが、最新リリースにはまだ実装/修正されていませんか?

当社のリリースポリシーは、安定版ブランチに新機能やリソースの変更を導入しないことです。バグの修正、新機能の導入、または機能の動作の変更は trunk で行います。重要なバグ修正のみが安定版ブランチにマージされ、安定版ブランチからリリースを作成します。

このポリシーは、安定版ブランチに新しいバグが入るのを防ぐために設けています。結局のところ、それは安定版ブランチと呼ばれています。

リクエストされた機能/報告されたバグは、trunk で修正/実装されていても、このポリシーのために安定版ブランチにマージされませんでした。そのため、最新リリースで変更が見られないのです。

冒険好きなら、ナイトリービルドを使用できます: https://nightlybuilds.tortoisesvn.net/latest/

TortoiseSVN は Eclipse とうまく連携しません

Eclipse は通常の操作の一部としてディレクトリをコピーし、Subversion ワーキングコピーでは .svn ディレクトリもコピーします。これにより、TortoiseSVN は bin ディレクトリにバージョン管理されたファイルがあると考えます。

TortoiseSVN を使い続け、これが起こるのを防ぎたい場合は、Eclipse のソース除外リストに '**/.svn/' を追加する必要があります。

しかし、Eclipse には Subclipse と呼ばれる独自の Subversion プラグインがあり、Eclipse を SVN 対応にし、根本的な問題を修正します。 https://github.com/subclipse/subclipse で見つけることができます。Subclipse をインストールしたら、フレッシュチェックアウトを行う必要があります。インストール前に作成されたチェックアウトは修正されません。

Internet Explorer でファイルをアップロードする際のセキュリティ警告

Internet Explorer で Web フォームを使用してアップロードするファイルを選択すると、プログラムが Web コンテンツを開こうとしているというセキュリティ警告が表示され、TortoiseSVN が原因として特定される場合があります。

パニックにならないでください! これは Internet Explorer セキュリティモデルの (誤った) 機能です。TortoiseSVN はシェル拡張機能であるため、アイコンオーバーレイとコンテキストメニューを提供するために、ファイルを開くダイアログが作成されるたびに自動的にロードされます。
警告を停止するには 2 つの方法があります。

  1. TortoiseSVN の設定で、アイコンオーバーレイセクションに移動し、エクスプローラーでのみオーバーレイとコンテキストメニューを表示するボックスをオンにします。
  2. 警告が表示されたら、このアプリケーションに対して二度と表示しないとマークされたボックスをオンにします。

スマートカードを挿入するためのダイアログが繰り返し表示される

スマートカードソフトウェアを使用している場合、TortoiseSVN がリポジトリに接続しようとするたびに、スマートカードを挿入するように求めるダイアログが表示されることがあります。

残念ながら、一部のスマートカードベンダーはこれをバグではなく機能と考えています。ユーザーをイライラさせる以外の目的を果たしていなくても。

リポジトリから証明書が要求された場合に、TortoiseSVN が Windows 証明書ストアへのアクセスを試行するのを防ぐには、レジストリキー HKCU\Software\TortoiseSVN\OpenSSLCapi を DWORD として作成し、値を 0 に設定します。

「ワーキングコピーと比較」が設定された diff ビューアーを使用しない

ログダイアログから「ワーキングコピーと比較」を実行すると、別の差分ビューアツールを使用するように設定している場合でも、TortoiseMerge が起動します。

これはバグではありません。このコマンドは、2 つのファイルを比較するわけではありません。実際には、パッチファイルを作成し、そのパッチファイルをワーキングコピーに適用するとどうなるかを示すために TortoiseMerge を起動します。そして、パッチファイルを適用できる他の UI ツールを知らないため、TortoiseMerge が起動します。設定した差分ビューアでは実行できません。

デバッグシンボルはどこにありますか？

公式リリースとナイトリービルドの両方のデバッグシンボルは、DrDump.com でホストされています。

デバッグシンボルにアクセスするには、シンボルサーバーを https://www.crash-server.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv を使用するようにデバッガーを設定します。

デバッグシンボルサーバーの使用方法については、この 記事 を参照してください。

どうすれば...

... author、revision、date、commit-time などのキーワード情報をファイルに追加できますか？

Subversion ブックの Subversion プロパティ svn:keywords について読んでください。

TortoiseSVN では、こちら で説明されているようにプロパティを設定します。

... ファイル名の大文字/小文字を変更できますか？

Subversion は、Linux で使用されているような大文字と小文字を区別するファイルシステムで動作するように設計されています。Windows の大文字と小文字を区別しないファイルシステムに関しては、期待どおりに動作しない場合があります。その一例として、Makefile を MAKEFILE にリネームするなど、大文字と小文字のみを変更してファイル名を変更する場合です。Subversion 1.7 より前は、Subversion は両方の名前が短時間同時に存在することを要求していたため、ワーキングコピー内でこれを簡単に行うことができず、Windows はこれをサポートできませんでした。

最も簡単な方法は、リポジトリブラウザを使用して直接リネームすることです。

  1. ワーキングコピーの変更をコミットします。
  2. リポジトリブラウザを使用して、リポジトリ内で直接ファイル名を UPPERcase から upperCASE にリネームします。
  3. ワーキングコピーをアップデートします。

Subversion 1.7 以降では、ワーキングコピー構造全体が変更されたため、これはもはや問題ではなく、通常の TSVN->リネームコマンドを使用してファイルを簡単にリネームできます。

... コミット後にログメッセージまたは author を変更できますか？

ログダイアログを呼び出し、編集するリビジョンを 右クリック します。次に、コンテキストメニューから「作成者を変更」または「ログメッセージを変更」を選択します。サーバーにこれらの変更を承認させるには、作成者またはメッセージの変更を許可する pre-revprop-change フックがリポジトリにインストールされている必要があります。デフォルトのインストールでは、作成者とログメッセージへの変更は拒否されます。

... TortoiseSVN のドロップダウンリストをクリアできますか？

TortoiseSVN の設定ダイアログから、保存されたすべてのデータをクリアできます。対応するボタンをクリックするだけです。

単一のアイテムは、Shift+Delete を押すことでドロップダウンリストから完全に削除できます。

... コンピューターからリポジトリを完全に削除できますか？

えへん: フォルダを選択して Delete を押します (キーボードのキーには Del のみとラベル付けされている場合があります)。

真面目な話、隠しファイルや設定はありません。リポジトリは完全に 1 つのフォルダツリーに含まれています。

ワーキングコピーにも同じことが当てはまります。ワーキングコピーをゴミ箱に送ると、多数の小さなファイルのために、今後の削除が著しく遅くなる可能性があります。その後すぐにゴミ箱を空にすることをお勧めします。

... ログをテキストファイルに出力できますか？

ログダイアログを使用します。必要なエントリをすべて選択し、Ctrl+C を押します。次に、お気に入りのテキストエディタで Ctrl+V (または貼り付け) を使用します。

ログメッセージを自動的に処理する場合、または xml 形式で必要な場合は、コマンドラインクライアントを使用できます。

... プロジェクトのリビジョン番号をプロジェクトに取得できますか？

プログラムのバージョン番号にリビジョン番号が必要な場合は、それを行うための追加ツールが必要です。ツール SubWCRev.exe は、当社の Web サイトのダウンロードページまたは bin の下の TortoiseSVN フォルダにあります。

このツールは、ワーキングコピー全体を最も新しいリビジョンを探して走査します。そのリビジョンが見つかると、次の文字列のすべての出現箇所を置き換えます。

$WCREV$
この文字列は、ワーキングコピーのリビジョン番号に置き換えられます。
WCMODS?Modified:Not modified$
ローカルに変更がある場合は、疑問符とコロンの間の文字列が挿入されます。ローカルに変更がない場合は、コロンとドル記号の間の文字列が挿入されます。上記の例では、Modified または Not modified です。
$WCDATE$
ワーキングコピーの最新リビジョンの日付に置き換えられます。

例として、TortoiseSVN ソースツリー の version.in ファイルを参照してください。このファイルは TortoiseSVN とそのリソースファイルで使用されています。SubWCRev.exe ツールは、次のようにビルドスクリプトから呼び出されます。SubWCRev.exe path\\to\\working\\copy version.in version.h これは、上記のすべての文字列がワーキングコピーの値に置き換えられた新しいファイル version.h を作成します。version.h ファイルはプロジェクト自体で使用され、バージョン情報のリソースファイルに含まれています。

... Subversion が自動マージを実行しないようにするには？

一部の人々は、Subversion がアップデート時に他の人からの変更を自分のローカルワーキングコピーの変更と自動的にマージすることを好みません。これらのファイルを強制的にコンフリクト状態にして、都合の良いときに手動でマージする方法を次に示します。

  1. TortoiseSVN->設定->Subversion 設定ファイルで、編集ボタンをクリックします。
  2. [helpers] セクションを変更して、次の 2 行を追加します。
    diff-cmd = "C:\\false.bat"
diff3-cmd = "C:\\false.bat"
    (二重バックスラッシュに注意してください)
  3. 次の 2 行を含むファイル C:\false.bat を作成します。
    @type %9
@exit 1

これにより、オートマージは毎回失敗し、ファイルは強制的にコンフリクト状態になります。

'type %9' 行が奇妙な理由ですが、diff3-cmd はマージされた出力を stdout に送信するためです。Subversion はこれを受け取り、ローカルファイルをマージ結果で上書きします。この行を追加すると、空のローカルファイルを取得することを回避できます。

... 現在のサンドボックス/リポジトリを確認するには？

ワーキングコピー内のフォルダを右クリックし、エクスプローラーのコンテキストメニューから「プロパティ」を選択します。次に、プロパティダイアログで、「Subversion」タブに切り替えます。選択したフォルダに関するあらゆる種類の情報 (それが指している URL を含む) を確認できます。

この情報をすばやく確認するもう 1 つの方法は、コンテキストメニューから「再配置」を選択し、最初の URL を確認することです。WC を再配置する必要がないため、このダイアログを中止するだけです。

... TortoiseSVN をサイレント/自動インストールするには？

MSI インストーラーを次のように起動するだけです。

msiexec /package TortoiseSVN.msi /quiet INSTALLDIR="path/to/install/dir"

エラーメッセージ

'XXX.svn-base' を 'XXX.tmp' にコピー/移動できません：システムは指定されたファイルを見つけることができません。

このエラーメッセージは通常、ワーキングコピーをアップデートしようとするときに発生します。このエラーの原因は次のいずれかです。

  • リポジトリに実際には 2 つの異なるファイルがあり、名前は大文字と小文字のみが異なります。Windows ファイルシステムは大文字と小文字を区別しないため、これは Windows チェックアウトでは機能しません。いずれかのファイルが誤って追加された可能性が高いため、どちらであるかを確認し、間違ったファイルに変更がコミットされていないことを確認してから、削除する必要があります。
  • Windows で違法な (Windows で違法な) ファイル名を持つファイルがあります。たとえば、「con」、「lpr」、「com」などの名前は、デバイス名であるため、Windows では違法です。そしてもちろん、「/\*?:|」やその他の特殊文字を含む名前も、Windows (NTFS および FAT) では不可能です。

そして、この場合、エラーメッセージが本当に役に立たないことは承知しています。しかし、エラーメッセージは Subversion ライブラリから来ており、私たち自身では変更できません。

問題を解決し、再発を防ぐためのいくつかの方法があります。これらの 手順 を参照してください。

'.svn/tmp/entries' を '.svn/entries' に移動できません：ファイルまたはディレクトリが破損していて読み取れません。

このエラーメッセージは通常、ワーキングコピーをアップデートまたはコミットしようとするときに発生し、Windows 7 システムでよく見られるようです。これは、Subversion が移動または変更する必要があるファイルを別のプロセスがハンドルを保持していることが原因です。これはウイルススキャナーである可能性があります。ウイルススキャナーを構成して、ワーキングコピーとリポジトリがスキャンから除外されるようにします。

注: Win7 にはバグがあり、このエラーメッセージが必要以上に多く表示される原因となっています。このバグはサービスパック 1 で修正されています。詳細については、この投稿 を参照してください。

ファイル 'XXX\nnn-n.txn\changes' を開けません：プロセスは別のプロセスで使用されているため、ファイルにアクセスできません

このエラーを報告する人々は、多くの場合、ランダムに発生し、多くの場合、大規模なコミットの途中で発生すると述べています。コミットを再試行すると成功する場合もあれば、別のポイントで失敗する場合もあります。

最も可能性の高い原因は、ウイルススキャナーが不必要にファイルハンドルを開いたままにしていることです。スキャナーを無効にするか、リポジトリを無視するように設定してみてください。

同様のエラーがワーキングコピーで発生する可能性があります。そこにある .svn フォルダを無視してみてください。

'XXX' の追加に失敗しました：同じ名前のオブジェクトがすでに存在します

このエラーメッセージは通常、ワーキングコピーをアップデートしようとするときに発生します。これは、Subversion が既存のローカルデータを削除または上書きしないためにスローされます。このエラーが発生する理由として、次の 3 つが考えられます。

  1. 最近誰かによって追加されたファイルと同じ名前のローカルのバージョン管理されていないファイルがあります。この場合、解決策は、ローカルファイルをどこか別の場所に移動する (またはリネームする) ことです。その後、アップデートします。その後、2 つのファイルを何らかの方法で結合する必要があるかどうか、または名前の選択が単なる偶然である場合は、ファイルに別の名前を付けることができます。
  2. ファイルがリポジトリ内でリネームされましたが、Install.txt から install.txt のように、大文字と小文字のみが異なり、ローカルに変更があります。アップデートすると、変更されたローカルファイルがバージョン管理されていないように見える状況 (1) に陥ります。どこか別の場所に移動し、アップデートしてから、混乱を整理します。
  3. リポジトリに実際には 2 つの異なるファイルがあり、名前は大文字と小文字のみが異なります。Windows ファイルシステムは大文字と小文字を区別しないため、これは Windows チェックアウトでは機能しません。いずれかのファイルが誤って追加された可能性が高いため、どちらであるかを確認し、間違ったファイルに変更がコミットされていないことを確認してから、削除する必要があります。

'<path>' の OPTIONS：401 Authorization Required <url>

バージョン 1.4.x にアップグレードすると、突然リポジトリにアクセスできなくなります。すべての試行は、次のエラーメッセージで拒否されます: OPTIONS of 'path': 401 Authorization Required 'url'

この理由の 1 つは、バージョン 1.4.x でアクティブ化された SSPI による自動認証です。つまり、TortoiseSVN は、Windows ドメインコントローラーにログインしているユーザーの資格情報を使用して自動的に認証を試行するようになりました。

ドメインコントローラーに対して SSPI で認証するようにサーバーを設定し、ドメインコントローラーにユーザーアカウント GUEST が有効になっていない場合は、問題ありません。しかし、ユーザーアカウント GUEST がアクティブな場合、すべての認証はそのユーザーで成功します。通常、ユーザー GUEST にリポジトリへのアクセス権を与えることはありません。そのため、認証は成功しますが、承認は失敗します。

失敗するもう 1 つの理由は、ワークステーションへのログインに使用するアカウントとは異なるアカウントをリポジトリアクセス用に設定している場合です (ただし、その場合、そもそもなぜ SSPI 認証を使用しているのか疑問に思います)。

この問題を解決するには、次のオプションがあります。

  • ドメインコントローラーで GUEST アカウントを無効にする
  • ワークステーションとリポジトリへのアクセスに同じアカウントを使用する
  • リポジトリの SSPI 認証を無効にする
  • ユーザー名の大文字と小文字を確認してください。アクセスファイル内のユーザー名を小文字に変更することも、この問題を解決する可能性があります。

このクライアントは古すぎてワーキングコピー 'XXX' を操作できません

完全なエラーメッセージは次のとおりです: This client is too old to work with working copy '.'; please get a newer Subversion client.

Subversion バージョンが高い Subversion クライアントを使用した後、古いバージョンの Subversion クライアントでリンクされた Subversion クライアントでコマンドを実行しようとすると、このエラーメッセージが表示されます。たとえば、ワーキングコピーで 1.4.x クライアントを使用し、同じワーキングコピーで svn 1.3.x クライアントを試行する場合などです。

この理由は、Subversion 1.4 以降では、すべてのコマンドでワーキングコピーが透過的にアップグレードされるためです。ただし、ワーキングコピー形式がアップグレードされると、古いクライアントは新しい形式を認識しないため、ワーキングコピーにアクセスできなくなります。

これを「修正」する唯一の解決策は、このエラーメッセージを表示したクライアントをアップグレードすることです。または、古いクライアントでフレッシュチェックアウトを実行します。

ワーキングコピーが古くなっています

ワーキングコピーに対して行った変更をコミットしようとすると、このエラーメッセージが表示されます。通常、これは、他の誰かがリポジトリ内の同じファイルを変更したために発生します。

つまり、アップデート コマンドを使用して、ワーキングコピーをリポジトリと同じレベルにアップデートする必要があります。

特にリポジトリが変更されていないことを知っている場合、なぜこれを行う必要があるのか​​不明確な場合があります。答えは、ワーキングコピーはコミットによって完全にアップデートされるわけではないためです。変更されたファイルとフォルダのみが自動的にアップデートされます。新しく作成されたリポジトリの例を次に示します。

Add Folder in revision 1
Add File1 and File2 in revision 2
Modify File1 and commit in revision 3

現在、リポジトリはリビジョン 3 ですが、ワーキングコピーのリビジョンは次のようになっています。

Folder       : revision 1
Folder/File1 : revision 3
Folder/File2 : revision 2

ここで File2 を変更してコミットしようとすると、失敗します。クライアントは、File2 がローカルに変更されたリビジョン 2 であることをリポジトリに通知しますが、リポジトリはすでにリビジョン 3 です。その後、アップデートを実行すると、File2 もリビジョン 3 になります (もちろん、ローカルの変更はまだそこにあります)。

ブランチまたはタグを作成しようとすると、同じことが起こる可能性があります。答えは常に同じです: ワーキングコピーが古くなっている場合は、アップデートしてください!

標準出力に書き込めません

TortoisePlink は標準の plink コードを使用しますが、ウィンドウレスアプリとしてコンパイルされているため、エラーメッセージを送信する場所がありません。TSVN 設定->ネットワークで、SSH クライアントボックスを標準の plink を使用するように設定します。ここでは、エラーメッセージがコマンドボックスに表示されます。それが機能したら、同じパラメータで TortoisePlink を使用します。

「標準出力に書き込めませんでした」とは、Plink がエラーをスローしようとしたが、TortoisePlink に DOS ボックスがないため、エラーメッセージを書き込む標準出力がないことを意味します。

したがって、セットアップに何か問題があります。通常の plink プログラムで試して、実際のエラーメッセージが何であるかを確認し、セットアップを修正してください。

通常の plink がハングする場合は、間違ったパラメータが渡されています (設定ダイアログ、ネットワークタブ)。

もう 1 つの可能性は、SSH デーモンが svnserve バイナリを見つけられない可能性が高いことです。ターゲットユーザー (ここでは myuser) でサーバーにログインし、「which svnserve」と入力します。バイナリへのパスが表示されない場合は、このファイル (およびおそらく他の subversion バイナリ) をこのユーザーがグローバルにアクセスできるようにします。

400 Bad Request

REPORT request failed on '...' REPORT of '...': 400 Bad Request (http://...)

DAV リクエストをブロックするファイアウォールの背後にいます。ほとんどのファイアウォールはそれを行います。管理者にファイアウォールを変更するように依頼するか、http:// の代わりに https:// でリポジトリにアクセスしてください。そうすれば、SSL 暗号化でリポジトリに接続できます。ファイアウォールは (SSL ポートを完全にブロックしない限り) 干渉できません。

また、一部のウイルススキャナー (Kaspersky など) が干渉してこのエラーを引き起こすことが知られています。

403 Forbidden

PROPFIND request failed: 403 Forbidden

実際のリポジトリパスではなく、リポジトリの親パスを入力したことが原因である可能性があります。アクセスするリポジトリの名前を URL に追加してみてください。また、リポジトリ名の後に、URL に末尾の '/' スラッシュを追加する必要があります。

実際のエラーの詳細については、Apache エラーログを探してください。

405 HTTP Method Not Allowed

PROPFIND Request Failed - Error 405 HTTP Method Not Allowed

このメッセージにはさまざまな種類があります。次の場合にこのエラーが表示される場合があります。

  • PROPFIND Request Failed 古いバージョンの TortoiseSVN を使用して、リポジトリ自体の代わりにリポジトリの親パスをブラウズしようとしました。アクセスするリポジトリの名前を追加するか、TortoiseSVN を 1.2.3 以降にアップグレードしてみてください。
  • PROPFIND Request Failed 入力した URL の最後に '/' スラッシュを追加するのを忘れました。古いバージョンの TSVN では、リポジトリ名の後に '/' が必要です。これを忘れると、TSVN は URL からリポジトリ名を削除し、親ディレクトリへのアクセスを試みます。
  • PROPFIND Request Failed DAV リクエストを許可しないプロキシを介してリポジトリにアクセスしようとしています。通常、Web ブラウザでリポジトリを問題なくブラウズできますが、svn クライアントを使用するとこのエラーが発生します。プロキシ/ファイアウォールサーバーを構成して、DAV リクエストを通過させる必要があります。または、http の代わりに https を使用してみてください。ほとんどのプロキシは暗号化されたネットワークパケットを分析できないため、DAV リクエストをブロックできなくなります。
    このエラーのもう 1 つの可能性は、マシンで実行しているウイルススキャナー/ファイアウォールです。それらの多くは、気付かないうちに DAV リクエストをフィルタリングアウトします。スキャナー/ファイアウォールを無効にしてみてください。
  • Lock Request Failed リポジトリに存在しなくなったワーキングコピー内のファイルをロックしようとしました。ファイルをロックする前に、ワーキングコピーをアップデートしてください。

実際のエラーの原因の詳細については、Apache エラーログを探してください。

SVN+SSH: Connection closed unexpectedly

以前は機能していた svn+ssh://[email protected] 形式の svn+ssh 接続が、TortoiseSVN 1.5 で動作しなくなることが報告されています。これは plink に関連しているようで、PuTTY でデフォルトのホスト名を設定している場合に発生します。

これに該当する場合は、regedit または regedt32 を使用して HKEY_CURRENT_USER/Software/SimonTatham/Putty/Sessions/Default%20Settings/HostName をクリアすることで修正できます。

別のユーザーから、次のサーバー側の修正が報告されています。
  • ssh でアカウントにログインします。
  • cd ~
  • cp /etc/bashrc .bashrc
  • nano .bashrc
  • 「mesg y」行の前に # を付けます (コメントアウト)
  • Ctrl+X で終了し、保存を求められたら Y を押します。

♥ 2004-2024 – TortoiseSVN チーム。ぜひ共有してください。