問題タブ [msscci]

ソース管理からいくつかのファイルを Visual Studio 2003 の XP モードのインスタンスに取り込むために、(Visual Studio 2003 で) [ファイル] > [ソース管理] > [ソースから開く] を選択して、ソース管理からいくつかのファイルを取り込むことができました。コントロール...TFSサーバーに接続し、目的のプロジェクトに移動して選択します。

ただし、その操作では *.sln ファイルが取り込まれなかったため、そのプロジェクトを開くことができません (*.cs ファイルは存在しますが、その「ホスト」sln ファイルは存在しません)。

次に、[ファイル] > [ソース管理] > [Team Foundation Server MSSCCI プロバイダー] を介して不足しているファイルを添付/持ち込もうとしました

これを行うと、「Visual Studio変換ウィザード」に暖かく歓迎されます（私は思う）が、動作しているように見えますが、* .slnファイルが作成されたため、* .slnファイルも引き継がれませんVSの異なるバージョンで（一見喜んで教えてくれます）-VS 2003 / VS 2010（シェル）の不一致について話していることは間違いありません...？

したがって、ファイルを配置しようとしているローカル フォルダーに *.sln がありません。

*.sln ファイルは TFS サーバー領域に存在します - [ファイル] > [ソース管理] > [ソース管理から開く] > [Team Foundation Server に接続] > [フォルダー ダイアログを展開] > [必要なプロジェクトに移動] を選択すると、これが表示されます:

...しかし、強調表示し、2 回クリックしても、HUtilCE.sln はそれを [ファイル名] コンボ ボックスに転送しません - そこに手動で入力する必要がありますが、[開く] ボタンを押すと、「不明なエラーが発生します。 ."

では、このプロジェクトにアタッチするには、どのフープとどの順序でジャンプする必要がありますか。そして、その激しい急降下をする前に、どのグレードの難燃剤を尻尾にスプレーする必要がありますか?

どういうわけか、プロジェクトでソース管理バインディングが混同され、ローカル ファイルをサーバー上の正しい場所にバインドしようとしています。最初にプロジェクトのバインドを解除しようとしていますが、バインドを新たに設定して「ソリューションをソース管理に追加」しようとすると、「ソース管理に追加しようとしているプロジェクト PDAClient.csdproj を追加できません。項目 AppSettings.cs は、選択した場所で既にソース管理下にあるため、 "

AppSettings.csがアルファベット順で最初のファイルであるため、問題のあるファイルとしてAppSettings.csのみを選択したようです。これは、プロジェクトから一時的に削除して再試行したため、同じように次のアルファ オーダーのファイルについて不平を言ったからだと思います。

TFSの裏をかくために、「MSSCCPRJ.SCC」の名前を「MSSCCPRJ.SCCHide」に変更し、「PDAClient.vssscc」の名前を「PDAClient.vsssccHide」に変更しましたが、単に新しい「PDAClient.vssscc」を作成しました

(PDAClient はソリューションとプロジェクトの名前です)

VS 2003 File > Source Control > Change Source Controlから試すと、次のように表示されます。

次に、ソリューションの [バインド] を選択してから、その名を冠したプロジェクトを選択すると、次のように表示されます。

[参照] または [サーバー バインド] 列の省略記号ボタンをクリックすると、「点滅」するだけで、接続を確立するためのダイアログが開きません。

したがって、ソリューションのバインディングは「無効」ですが、プロジェクトのバインディングはおそらく有効です...

次に「OK」を選択すると、次のようになります。

...これは有望に見えますが (「はい! バインディングを修正してください!」)、「修正」ボタンを選択すると、何もせずに [ソース管理の変更] ダイアログに戻るだけです。だから私は最後に、しぶしぶ、「既存のバインディングを続行する」という他のオプションを選択し、次のことを確認します。

わかりました...それを機能させるにはプロジェクトをチェックインする必要があることがわかり、続行しようとしましたが、次のように表示されます。

Handheld/Development/Development/HHS に接続しようとしていることに注意してください。DEV は別のブランチです。これはリリース ブランチです。上記のソリューションのスクリームショットで、Path プロパティ (C:\Project\sscs\Handheld\Release (など) に設定) ではなく ...Development...(など) であることがわかります。 -in ツールを実行すると、サーバー バージョンが Dev ブランチ (目的のリリース ブランチではなく) からのものであり、ローカル バージョンが使用されていることがわかりました。しかし、私は得ました：

その後、プロジェクトのファイルの一部がチェックアウトされていることがわかったので、これでうまくいくのではないかと思いました。メソッド名を変更してテストしたところ、「チェックアウト中にエラーまたはユーザーのキャンセルが発生しました。一部のファイルがチェックアウトされていない可能性があります。(ファイルがチェックアウトされていませんでした。)」と出て、続いて、「影響を受けるファイルの一部を書き込み可能にできなかったため、リファクタリングを実行できませんでした」...そして、私の変更は自動的に取り消されました。

このプロジェクトに変更を加える必要があるため、明らかにこれは機能しません。

[ファイル] > [ソース管理] メニューに残っているものをいじくり回し、 [ソース管理からプロジェクトを追加...] を選択して、何が提供されるかを確認しました。まず、TFS に接続するためのダイアログが表示されます。やった。サーバー上の適切な場所に移動しましたが、これは問題なく、すぐに使用できます。

[OK] を選択すると、「ソリューションを保存するために選択したローカル フォルダーには、ソース管理サーバー フォルダー内のファイルと同じ名前のソリューション ファイルが 1 つ以上含まれています。」というダイアログが表示され、[上書き]、[キャンセル]、および [ヘルプ] ボタンが表示されます。

[上書き] を選択します。次に、ダイアログが表示されます。

PDAClient.sln を選択します (HHS はソリューション/プロジェクトの以前の名前でした)

ただし、その後 [開く] ボタンを選択すると、「フォルダー 'C:\Project\sscs\Handheld\Releases\6-4-0\HHS' は、既に使用されているため、ソリューションまたはプロジェクトには使用できません。別のソリューションまたはプロジェクトの一部を保存します。」

やむを得ず「OK」を選択するしかありません。

Any-Port-in-a-Stormism Syndrome の最終的な首から先の首輪を壊す可能性のある偉業として、[ File] > [Source Control] > [Team Foundation Server MSSCCI Provider]を選択します。これにより、XP モード内の VS 2003 内で Kafka 風の Windows 2010 シェルが呼び出されます。そこに表示される内容によると、セットアップは正しいです。Release プロジェクトのサーバーのコピーは、ローカル ファイルの Release フォルダーにバインドされています。

ただし、\Releases\HHS はグレー表示されており、サーバー フォルダーとローカル フォルダーの間に接続がないことを示しています。そして、Release セットアップ内のファイルのほとんど (すべてではありませんが、ほとんど) は、実際には Development フォルダーにローカルに保存されていることに注意してください。正しくバインドされている主要なファイルがいくつかあります。

すべての (数十の) 目に見えないファイル (最後の 2 つのスクリーンショットでは最初と最後のファイルのみが表示されています) も開発に関連付けられています。

\Releases\HHS の「バインド」タイプのコンテキスト メニュー項目はありませんが、「マップ ローカル」があります。表向きは既に正しくマップされていますが、試してみましたが、「ローカル フォルダーを C:\Project\sscs\Handheld\Releases\6-4-0\HHS に設定できませんでした。これは、既にローカル フォルダーであるためです。別のサーバー フォルダ。」

そこで、「有効な」バインディングを持つ\Development\HHS に移動します。繰り返しますが、間違ったローカル パス (Dev ではなく Releases) にバインドされていることに注意してください。

そのため、まずコンテキスト メニューの [マッピングの削除] を選択します。これにより、「ワークスペース マッピングを編集または削除する」機会が与えられます。ローカル フォルダーを Releases から Dev に変更します。よさそうです。Dev は Dev にバインドされ、バインディングは引き続き有効と見なされます。今回は本当にそうです（とにかく願っています）。

ここでリリースに注意を戻しますが、「マップ ローカル」というコンテキスト アイテムはもうありません...そして、サーバーの場所とローカルの間の正しい接続を示していますが、まだグレー表示されています...???

注: ファイルの「保留中の変更」リストは、強調表示された \Development\HHS と \Releases\HHS の両方と同じです。両方のケースで同じ 3 つのファイルがローカルの Releases フォルダーにあり、その他すべてがローカルの Dev フォルダーにあるように表示されます。フォルダ。

VS 2003 (TFS MSSCCI プロバイダーを実行している VS 2010 シェルの外) に戻り、[ソース管理の変更] に移動すると、ソリューションとプロジェクトの両方のステータスが [有効] になっていることがわかります...「 OK」ですが、多くのファイルが一致しないことがわかり、管理者に連絡するか、すべてを取得することで解決する可能性があります。暫定的に Select All を調べてみましたが、私のプロジェクトは Development にバインドされているとまだ表示されています。あぁぁぁぁぁぁぁぁぁぁぁぁぁぁ！！！

誰もこの狂気から抜け出すことができますか? ブリードオーバーや不一致なしで、Release ローカル フォルダーを指す Release サーバー フォルダーと Dev ローカル フォルダーを指す Dev サーバー フォルダーを取得するにはどうすればよいですか?

アップデート

今朝もソース管理エクスプローラー (TFS MSSCCI) を調べたところ、Dev\HHS が再び間違ったローカル パス (リリース) に設定され、接続されていました (それが、直面している -each- のグリフだと思います)。フォルダの左側にあるその他の垂直矢印が示す)。

Releases\HHS に関しては、接続されていませんでしたが (グリフなし)、右クリックして、セットアップした新しいフォルダーにマップすることができました。

これが私が今見ているものです（DEVのマッピングをローカルのリリースフォルダーからローカルのDEVフォルダーに再度変更した後です！）。

Dev HHS のプロパティ:

リリース HHS のプロパティ:

これがあなたにとって意味があるかどうかはわかりませんが、私には怪しいように見えます。

更新 2

狂気は今日も衰えない。私のソリューションは、2 つの保留中のチェックインがあると主張しています。

「チェックイン」を選択すると、確認ダイアログが表示されます。そこで「チェックイン」ボタンを押します。次に、[チェックイン - ソース ファイル] ダイアログが表示されます。そこでも「チェックイン」ボタンを選択します。しかし、「ファイルがチェックアウトされていません」と表示されます

上記の操作を繰り返すと、最後のメッセージは次のようになります。

???

IMO、最新の変更を保存したいときに、この面倒な獣を使用するのではなく、ファイルを圧縮するだけで多くの時間を節約できたでしょう。私は、より単純なアプローチを使用するよりも、「生産性」ツールをいじることに多くの時間を費やしています。この打ち砕かれた希望と巧妙で巧妙な汚いトリックの大釜に対する zip ファイルと優れた diff ユーティリティをください!

更新 3

プロジェクトを閉じて再度開くと、次のメッセージが 3 回続けて表示されます。

では、青い炎の中で誰がそのようなサーバーを見つけるようにあなたに言いましたか?!?!

それから私は得る：

そして最後にこれをもう一度：

ぐぐぐぐぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ！！！！！！！！！！！！！！！！！！

更新 4

ソリューションとプロジェクトのパスが正しい (リリース) 場合でも、プロジェクト内のファイルは次のように表示されます。

更新に示すように、[ブランチ] タブには、Dev が Release に進むことが示されています。それが正しいかどうかはわかりませんが、Release は Dev のブランチだったので、

また...？？？

とにかく、ファイル>ソース管理>チームファンデーションのプロパティから上記を参照してください

ただし、[ファイル] > [ソース管理] > [Team Foundation Server MSSCCI プロバイダー] を選択すると、バインドが正しいように見えます。HHS Dev プロジェクトにはローカル フォルダーの場所として Dev があり、HHS Release プロジェクトにはローカルの場所として Release フォルダーがあります。

誰がもっと混乱しているのかわかりません。私、たまたまこれを読んだ人、または TFS/MSSCCI 自体です。この種のことは、皮肉なことに、生産性を著しく低下させます。

チェックイン イベントをクライアント上の TFS 2013 にトラップするカスタム チェックイン ポリシー プラグインを開発しました。これは、特定のワークフロー ステータスを評価し、チェックインに関する意味のあるコメントを生成するために使用されます。これらのタスクでは、チェックインのためにユーザーが選択/関連付けたワーク アイテムの有効性が検査され、ワー​​ク アイテムの値を使用してコメントが生成されます。これは、Visual Studio の領域で完全に機能します。最近まで、TFS へのすべてのチェックインは Visual Studio 2013 を介して行われていました。新しいチームが参加し、XPA Magic を利用しています。標準の XPA エディターは、TFS 2013 の 32 ビット MSSCCI プロバイダーを使用して、TFS でチェックアウトとチェックインを実行しているようです。XPA エディターを介してコードをチェックインする場合、次のダイアログを使用して、ユーザーが自分の作業項目を選択/関連付け、コメントを追加できるようにします。

残念ながら、このダイアログを介してチェックインすると、機能が機能しなくなります。プラグイン プロジェクトをデバッグしました。このルートを介してチェックアウトすると、 Evaluate() 関数が呼び出され、 Microsoft.VisualStudio.TeamFoundation.VersionControl.PendingChanges.PendingChangesModelVS が公開されます。ただし、IN をチェックする場合、Evaluate() 関数は呼び出されません。

チェックイン イベントをトラップし、Visual Studio 経由でチェックインする場合と同じ (または同様の) 結果を達成することも概念的に可能ですか?

クライアント コンピューターには、TFS 2013.Update3 アプリケーション サーバーに接続する Windows 7 で実行されている Visual Studio Premium 2013 があります。

-

-

ねえエドワード、

私はあなたの返事を正しく解釈しているかどうか完全には確信が持てませんが、ここに行きます:-)

アイデアは、チェックイン時に、関連付けられたワークアイテムの詳細 (WI 番号、説明、その他のカスタム情報など) を含むコメントを作成することです。ファイルをチェックインすると、作成された変更セットのコメントに役立つ情報が含まれます。チェックイン時にコメント (文字列) が生成され、次のプロパティに設定されます。

完全な名前空間: {Microsoft.VisualStudio.TeamFoundation.VersionControl.PendingChanges.PendingChangesModelVS}.PendingCheckin.PendingChanges.Comment

したがって、チェックイン アクション中にここにコメントをプッシュする必要があります。また、チェックイン時に、データを抽出できる場所から少なくとも 1 つの WI が関連付けられていることが確実にわかります。これは強制されるためです。

デバッグでは、これらのアクションが実行されるたびに、次のイベントが発生することがわかります。

• チーム エクスプローラー内の更新時。(PendingCheckin.Policies.EvaluationState = 未評価)

• Windows エクスプローラーのコンテキスト メニュー [Team Foundation Server] からのチェックアウト。(PendingCheckin.Policies.EvaluationState = 未評価)

• Visual Studioでのチェックイン(PendingCheckin.Policies.EvaluationState = Evaluated )

チェックイン アクションのみに関心があることを確認すると、コードは次のものにのみ応答します。

ご覧のとおり、Windows エクスプローラーのコンテキスト メニュー "Team Foundation Server" を介したチェックインは Evaluate() 関数に到達しないが、同じコンテキスト メニューからのチェックアウトは到達するという問題が発生します。検出！

MSSCCI によって VFP プロジェクトの読み込みが遅くなる可能性はありますか? プロジェクトには 1000 以上のファイルがあり、ワークスペースはサーバーです。プロジェクトは約 120 秒以上ロードされます。読み込み中はネットワーク トラフィックが増加しますが、CPU とメモリに大きな変化はありません。プロジェクトの読み込みを最適化するにはどうすればよいですか?

解決：

いいえ、ロードが遅いのは、VFP でソース管理されている小さな大規模プロジェクトに MSSCCI プロバイダーを使用した結果のようです。

MSSCCI プロバイダーを使用して TFS に接続するソリューションがあります。TFS での使用に切り替えて、仲介者として MSSCCI をカットするにはどうすればよいですか?

[ツール] --> [オプション] --> [ソース管理] --> [現在のソース管理] で TFS を選択すると、アクティブなソリューションが閉じられるというメッセージが表示されます。もう一度開くと、ソリューションはまだ MSSCCI によって制御されており、私の選択は無視されます。

どんなアドバイスでも歓迎します。