シナリオ。Team Foundation Server 2010 ソース管理:
私はtfsの資格情報を持っていなかったので、別のユーザーの資格情報を使用してtfsにアクセスしてプロジェクトを取得し、それをローカルディレクトリにマップしましたが、問題なく動作していました。
ここで問題は、私は自分の tfs 資格情報を持っているので、ローカルに既にマップされているプロジェクトを自分のユーザー資格情報に切り替えることは可能ですか?
シナリオ。Team Foundation Server 2010 ソース管理:
私はtfsの資格情報を持っていなかったので、別のユーザーの資格情報を使用してtfsにアクセスしてプロジェクトを取得し、それをローカルディレクトリにマップしましたが、問題なく動作していました。
ここで問題は、私は自分の tfs 資格情報を持っているので、ローカルに既にマップされているプロジェクトを自分のユーザー資格情報に切り替えることは可能ですか?
ワークスペースの MSDN 定義「Visual Studio Team Foundation Server のワークスペースは、一連の作業フォルダー マッピングで構成されます。これらのマッピングは、ローカル ディスク上のクライアント側フォルダーの場所と、対応するリポジトリ フォルダーを表します。In addition, the name of the workspace owner and the name of the computer on which the workspace is used are also stored in Team Foundation Server.
」
したがって、ワークスペースには、ワークスペース マッピングを形成するユーザー名、マシン名、およびローカル フォルダーに関する情報があります。デフォルトでは、TFS は 2 人のユーザーがマシン上の同じフォルダーにマップされることを許可しません (当然のことです!)。オプション 1 を使用して、このデフォルトの動作を克服する方法があります。
オプション 1: パブリック ワークスペース機能を利用することです。あなたはそれについてもっと読む:パブリックワークスペース
オプション 2: WORKSPACES COMMANDで /UpdatUserName オプションを使用するには。ただし、このオプションは、ユーザー名の名前が変更されている場合にのみ機能します (セキュリティ識別情報 SID は同じままです)。SOあなたの場合、これはまったく別のユーザーであるため、機能しません。
オプション 3: シェルフセットを使用する: 古いユーザーのワークスペース全体をシェルブし、新しいユーザーの新しいワークスペースの上にシェルブを解除するだけです。これにより、すべての変更が確実に保持されます。
オプション 4: 古いワークスペースを削除して、それを新しいユーザー ID にマップするだけの場合。いつでもご利用いただけますtf workspace /delete <DEVBoxName>;<OldUser> /server:http://<SERVERName>
。詳細については、TF WORKSPACE Commandを参照してください。ワークスペースを削除すると、古い変更は保持されません。
私の変更がサーバーに保留され、それが失われないことを確認するため、私は個人的に Shelveset オプションを使用します。