問題タブ [source-control-bindings]

VS2010 TFSでソース管理への変更セットをチェックインした後、チェックインに関連付けられた作業項目を修正するにはどうすればよいですか。たとえば、チェンジセットにリンクする必要のある別の作業項目があることに気付いた場合、またはそれがバグ修正であり、間違ったバグ作業項目にリンクされていた場合はどうでしょうか。

リポジトリ ルートを特定のフォルダにマップする (例: に$/マップするD:\Home) ワークスペースがあります。これにより、リポジトリ内のデフォルトの「自然な」フォルダー構造が取得され、手動でマップする必要がなくなります。

デフォルトの TFS 構造の下にあるサブプロジェクトのペアがあり、最近別のフォルダーの下に移動しました。TFS は、それらがハード ドライブ上の特定の場所を指していたことを覚えていますが、必要なのは、(現在の) カスタム マッピングを失い、親フォルダーが指している場所に基づいてデフォルトのマッピングの場所を取得することです。 .

フォルダーを再マップするオプションは表示されますが、カスタム マッピングを単純に削除するオプションはありません。IIRC Visual Source Safe には、これを行う方法がありました。カスタム方法でフォルダーをマッピングするのをやめて、親フォルダーに基づいてデフォルトでマッピングされるように戻すだけです。しかし、TFSでもそれができるかどうかはわかりません...

違いがあるとすれば、これは VS2010 から使用されている TFS2005 です。

編集

これをより明確にするための例を次に示します。$/ がもともと D:\Home にマップされていたとします。したがって、$/Foo は「自然に」D:\Home\Foo にマップされます。$/Foo/Widget も自然に D:\Home\Foo\Widget にマッピングされました。その後、ウィジェットは $/Foo の下から $/Bar に移動されましたが、TFS は、D:\Home\Bar\Widgetにしたいときに、マッピングがD:\Home\Foo\Widgetであることをまだ伝えています。カスタム マッピングを削除し、ウィジェットを古い場所ではなく、親フォルダーの下の「自然な」場所にマップできるようにしたいと考えています。

ソース管理は奇妙に機能しています。

シナリオは次のとおり です。コンピューターを再フォーマットする必要がありました。私は最初にすべてをバックアップし、次にそれを吹き飛ばしました。すべてのバックアップはネットワーク上の仮想ハードドライブにあり、一時的に必要なものを取得するために接続できます。

Webサイト/プロジェクトを同じファイルの場所に再度追加しましたが、ソース管理が機能していないようです。

私は、2番目の開発者にはない編集をいくつか行いました。また、2番目の開発者がWebサイトにいくつかの新しい編集を加えましたが、ソース管理に適切に接続されていないため、それらの変更を取得できません。問題が何であるかについて誰かが何か考えを持っていますか？

奇妙な問題に直面しています。テスト コンピューターに TFS 2010 を新しくインストールし、クライアント コンピューターで Visual Studio 2010 Professional を使用しています。私のクライアントは、以前は同じバインディングを持つ別の TFS 2010 マシンに接続するように構成されていました。現在、クライアント マシンから既定のコレクションにチーム プロジェクトを作成できますが、ソース管理にソリューションを追加しようとしても何も起こりません。これは、「ソリューションをソース管理に追加」ボタンを物理的に押しても、ウィンドウやメッセージが表示されないことを意味します。もちろん、サーバー マシンにすべてのアクセス許可とグループ メンバーシップを設定し、クライアントとサーバーを数回再起動しました。どうすれば問題を解決 (または少なくとも診断) できますか?

IBM ClearCase によって制御されているプロジェクト ソースを開こうとしていますが、次のメッセージが表示されます。

どうすればいいのかわからない。私はすでにすべてを再インストールしました。Visual Studio 統合は既にインストールされていますが、エラー メッセージが表示され続けます。

誰もがこれに対する解決策を知っていますか?

回答: 解決策が見つかりました。Tools -> SourceControl で ClearCase を選択したところです。

Perforce ソース管理 (P4VS プラグイン) の下で、Visual Studio 2013 で C# ソリューションを開発しています。最初に Visual Studio をロードすると、perforce デポへの接続を問題なく実行できます。次に、「Perforce Depot でソリューション/プロジェクトを選択」を選択してプロジェクトを開きます...

ここから楽しみが始まります。P4 ファイル チューザー ウィンドウで、デポが表示され (良好)、そのディレクトリをナビゲートできます (これも良好)。ただし、ディレクトリを展開すると、Perforce Source Control の出力ウィンドウにエラーが表示されます。たとえば、デポのルート ディレクトリを展開すると、次の (エラー) メッセージが表示されます。

E_WARN: //depot/* - クライアント ビューにないファイル

展開するすべてのディレクトリについてなどです。

ソリューション ファイルを開くと、さらに楽しくなりました。恐ろしい「ソース管理 - データベースにアクセスできません」という警告ダイアログが表示されます。次の内容が含まれます。

関連するソース管理プラグインがインストールされていないか、初期化できませんでした。

• 一時的に制御されていない作業 - Microsoft Visual Studio は、ソリューションを閉じて再度開いた後、ソリューションまたはプロジェクトをソース管理に再接続しようとします。

• 切断モードでオフラインで作業します (グレー表示されています... 詳しくは説明しません)

• ソース管理の関連付けバインディングを完全に削除する

「一時的に制御されていない作業」を選択すると、ソリューションが Perforce ソース管理の外部に読み込まれます。良くない。

ソース管理下でソリューションを開くには、[ツール] -> [オプション] -> [ソース管理] に移動し、ソース管理プラグインとして P4VS を再度選択してから、ソース管理外で開いた同じソリューションを再度開く必要があります。これで問題なく動作し、Perforce Source Control の下でソリューションを開いています。

私の推測では、これはソース管理バインディングと関係があると思いますが、そのような問題を処理する方法については、まったく手がかりがありません。いつものように、すべての助けに感謝します!

質問が 2 つあります。

1. Asp.NET Web プロジェクト (mvc または Web フォーム) を作成すると、プロジェクト フォルダーの隣に、依存アセンブリ用の別のフォルダー (パッケージ) が作成されます。これらのファイルをチェックインする必要がありますか?

2. ある種のファイルをチェックインしたくない場合、保留中の変更に表示されないようにするには、これらのファイルに対して何をする必要がありますか?

こんにちは、4 つのプロジェクト (*.vcproj) を持つソリューション (VS2013、vc++) があります。それぞれが EXE プロジェクトです。これは、私の win8 マシンの非ソース バージョン管理の場所に保存されます:: 「Documents/NoSourecControlFolder/」で言います。

ここでは、すべてのプロジェクトが正常にコンパイルされています。

ここで、この「」フォルダを、ソース バージョン管理以外の場所からソース バージョン管理の場所「perforce」に「Documents/P4_workspaces/WorkspaceABC/」と移動しました。

この *.sln の 4 つのプロジェクトのうち 1 つのプロジェクトが正常にコンパイルされていないことがわかります。

代わりに、このようなエラーをスローし、コンパイルを開始しません::

エラーは、ファイル名が長すぎることを示していますが、まったく同じプロジェクトが別の非ソース管理場所で完全に正常にコンパイルされていました。また、このファイル「 Release\ProectABC.vcxproj.FileListAbsolute.txt」がどこにも見つかりません。

このリンクを参照した後、これがファイルの場所の変更に関係しているというヒントを得ました。 リンク

どんな助けでも本当に役に立ちます。ありがとう。

この問題を説明するのは非常に難しいため、質問に基づいて詳細を追加する必要がある場合があります。

開発には TFS と Visual Studio 2013 を使用しています。

次のブランチがあります。

開発ブランチ
- $/ProjectName/Development/Development
- $/ProjectName/Development/201406 June
- $/ProjectName/Development/201407 July
- $/ProjectName/Development/201408 August

次のワークスペース マッピングがあります。

新しい月が始まると、dev にブランチ (例: 201408 August) を作成し、(上記のトップレベルのマッピングに加えて) 次のマッピングを設定します。

これにより、ワークスペースを簡単に変更し、使用するブランチを選択するのに役立ちます。多くの参照や IIS 内のものを変更する必要はありません。私が作業しているブランチに関係なく、すべてが常に C:\Projects\ProjectName\Development\Development を指しています。

その月の開発が完了したら、すべての作業がチェックインされていることを確認します (少なくとも 1 日に 1 回は常にチェックインします)。次に、ワークスペース マッピングを削除して、すべてがトップ レベルのマッピングによってのみ再びマッピングされるようにします。次に、Development/2014 August を Development/Develop にマージします。

必要なマージに満足したら、Development/Development にチェックインすると、作業は完了です。

これはすべて、まさに私が望んでいる方法ですが、問題があります。

何らかの理由で、VS はプロジェクトが Development/201408 August にあったことを記憶しているため、Development/Development ソリューション ファイルを開くと、プロジェクトは Development/201408 August を指しています。

次に、プロジェクトを削除し、正しい場所 (開発/開発) から追加します。その後、プロパティを見ると、Development/201408 August に変更されています。DOH!

問題のあるプロジェクトを削除
する ソリューションを保存する
Visual Studio を閉じるソリューション
の横にある *.suo ファイルを削除する
VS を再度開く
プロジェクトを再度追加する
保存する解決

そして、それは修正されるでしょう。これは本当です。問題を解決しますが、誰かがなぜこれが起こるのか教えてくれることを願っています.なぜなら、私のソリューションには35以上のプロジェクトがあり、毎月これを行うことは不可能だと確信しています.非常に迷惑です。

ワークスペースのマッピングが変更された後、必ず最新バージョンを再度入手してください。また、すべてのファイルを上書きして特定しようとしました。何も機能していないようです...

何か案は？

編集

言い忘れましたが、sln ファイルを XML として開くと、プロジェクトへのパスは実際には正しいのですが、VS 内からプロジェクトのプロパティを表示すると、正しくありません。