Visual Studio의 소스 제어 통합은 Perforce와 어떻게 작동합니까?

Visual Studio의 소스 제어 통합은 Perforce와 어떻게 작동합니까?

---

우리는 Perforce와 Visual Studio를 사용하고 있습니다. 분기를 만들 때마다 "소스 제어에서 열기"를 사용하지 않는 한 일부 프로젝트는 소스 제어에 바인딩되지 않지만 다른 프로젝트는 상관없이 작동합니다. 내 조사를 통해 관련된 몇 가지 사항을 알고 있습니다.

.csproj 파일에는 다음 설정이 있습니다.

• <SccProjectName>
• <SccLocalPath>
• <SccAuxPath>
• <SccProvider>

때로는 모두 "SAK"로 설정되지만 때로는 그렇지 않습니다. "SAK"라고 말하면 일이 더 잘 작동하는 것 같습니다.

.sln 파일에는 많은 프로젝트에 대한 설정이 있습니다.

• SccLocalPath #
• SccProjectFilePathRelativizedFromConnection #
• SccProjectUniqueName #

(#은 각 프로젝트를 식별하는 번호입니다.) SccLocalPath는 솔루션 파일에 상대적인 경로입니다. 종종 "."이고, 프로젝트가있는 폴더이고, ".."또는 ".. \ .."인 경우도 있으며, 위의 폴더를 가리키는 것은 좋지 않은 것 같습니다. 솔루션 폴더. 상대화 된 것은 해당 폴더에서 프로젝트 파일로의 경로 입니다 . SccLocalPath가 프로젝트 폴더를 가리키는 경우 완전히 누락됩니다. SccLocalPath에 ".."가있는 경우이 경로에는 분기간에 동일하지 않은 폴더 이름이 포함될 수 있으며 이로 인해 문제가 발생한다고 생각합니다.

그래서 마침내 내가 알고 싶은 세부 사항에 도달하려면 :

• "소스 제어 변경"을 수행하고 프로젝트를 바인드하면 어떻게됩니까? Visual Studio는 프로젝트 및 솔루션 파일에 넣을 내용을 어떻게 결정합니까?
• "소스 제어에서 열기"를 수행하면 어떻게됩니까?
• SccLocalPath 및 SccProjectFilePathRelativizedFromConnection이 참조하는 "연결"폴더는 무엇입니까? Visual Studio / Perforce는 어떻게 선택합니까?
• 솔루션의 새 분기를 만들 때에도 소스 제어 바인딩이 계속 작동하도록하는 몇 가지 권장되는 방법이 있습니까?

---

2012 년 6 월 추가 : 더 이상 Perforce를 사용하지 않으므로 보증 할 수는 없지만 아래 KCD의 답변을 살펴보십시오 . 분명히 개발중인 새로운 P4 VS 플러그인 이 있습니다. 이 모든 엉망진창이 해결되기를 바랍니다!

---

소개

저는 Visual Studio의 Perforce 통합이 "끔찍하다"는 주장에 동의하지 않습니다. 오히려, 나는 그것을 "기본 경험은 최적이 아니다"라고 정의 할 것이다. :-). 다음 섹션에서는 프로젝트 / 솔루션 설정에 대한 통합 및 권장 사항에 대한 나의 이해에 대해 설명합니다.

소스 제어 통합이 어떻게 작동하는지에 대한 세부 사항에 관심이 없다면 Weeble의 질문에 대한 답변을 요약하는이 답변의 끝으로 건너 뛸 수 있습니다.

면책 조항 : 다음 섹션은 경험적 경험을 기반으로 한 추측에 불과하지만 여러 프로젝트 (각 프로젝트에는 여러 실험 / 트렁크 / 유지 관리 / 릴리스 분기가 있고 때로는 여러 솔루션 파일이 문제없이 여러 해에 걸쳐 있음)에서이 기술을 사용했습니다. ). 단점은 프로젝트 파일 을 수동으로 업데이트 해야한다는 것입니다. 그러나 2 분의 투자는 프로젝트의 수명 동안 상당히 훌륭하게 IMHO :-)됩니다.

솔루션 대 프로젝트

Visual Studio는 초기 솔루션로드 중에 솔루션 파일과 각 프로젝트 파일의 소스 제어 바인딩 정보를 사용합니다. 그런 다음이 바인딩 정보는 name.suo 파일에 저장 됩니다 (이름 .sln 을 솔루션으로 사용한다고 가정 ). suo 파일은 숨김 플래그 로 표시 되므로 파일 탐색기에서 볼 수 없습니다 ( "Hidden 파일 및 폴더 "옵션).

문제가 발생한 경우 소스 제어 공급자에 다시 바인딩하는 가장 쉬운 방법은 적절한 suo 파일 을 삭제하고 솔루션을 다시 여는 것입니다. suo 파일이 생성 된 후에는 <Scc *> 요소에 대한 변경 사항이 적용되지 않습니다.

초기 솔루션을 여는 동안 솔루션 파일에 저장된 바인딩 정보와 프로젝트 파일에 저장된 정보 사이에 불일치가있는 경우 Visual Studio는이 문제를 해결하려고합니다 (때로는 솔루션의 정보를 선택할 것인지 아니면 프로젝트의 정보는 불일치를 해결하기 위해 "마스터"로 사용되어야합니다) :

Visual Studio가 DRY (Do n't Repeat Yourself) 원칙을 위반하는 이유는 무엇입니까? 나는 모른다. 나는 이것이 역사적인 이유를 가지고 있으며 Visual Source Safe라고 불리는 악몽의 요구와 밀접하게 연결되어 있다고 생각합니다 :-).

"올바르게"설정하는 방법은 무엇입니까?

새로운 또는 기존 솔루션 / 프로젝트를 Perforce에 추가 할 때는 항상 빈 솔루션을 만드는 것으로 시작합니다 ( "빈 솔루션 소스 제어"섹션 참조). 그런 다음이 빈 솔루션에 프로젝트를 차례로 추가합니다. 단계는 추가되는 프로젝트가 이미 존재하는지 ( "기존 (바인드되지 않은) 소스 제어"섹션 참조) 또는 "기존 (바인드 된) 프로젝트 소스 제어"섹션 참조) 또는 새 프로젝트를 만들어야하는지 (참조 : "소스 제어 새 프로젝트"섹션).

빈 솔루션 소스 제어

새 빈 솔루션을 소스 제어에 추가하려면 다음을 수행하십시오.

1. Visual Studio 시작, "새로 만들기"-> "프로젝트 ..."-> "기타 프로젝트 유형"-> "빈 솔루션"; 솔루션 이름 및 위치 입력, "OK"버튼
2. "파일"-> "소스 제어"-> "소스 제어에 솔루션 추가 ..."
3. 연결 대화 상자에서 적절한 P4 서버 포트, 클라이언트 및 사용자를 입력합니다 (선택한 클라이언트의보기에는 1 단계에서 선택한 위치가 포함되어야합니다).
4. "보기"-> "보류중인 체크인"-> "체크인"-> 제출 대화 상자에서 "제출"버튼을 누르는 대신 "취소"를 사용하십시오.
   이유 : "체크인"작업은 새 파일 "name.vssscc"를 만든 다음 "name.sln"과 "name.vssscc"를 모두 Perforce의 기본 변경 목록에 추가합니다. 제출 대화 상자를 취소하면 "추가"작업을 보류 상태로 유지하고 P4에 제출하기 전에 파일을 편집 할 수 있습니다.
5. Visual Studio 닫기

6. 자주 사용하는 편집기에서 name.sln 파일을 열고 (메모장, 정말 절실한 경우 :-)) 두 개의 새 줄 ( SccProjectName0 및 SccProvider0 )을 추가 합니다. 이제 빈 솔루션 파일에 다음과 같은 소스 제어 섹션이 있어야합니다.

   GlobalSection(SourceCodeControl) = preSolution
       SccNumberOfProjects = 1
       SccLocalPath0 = .
       SccProjectName0 = Tutorial
       SccProvider0 = MSSCCI:Perforce\u0020SCM
   EndGlobalSection
   

   값은 다음과 같이 선택해야합니다.

   • SccProjectName0 : "소스 제어 변경"대화창에 "서버 바인딩"으로 표시 될 임의의 문자열. 이 이름은 동일한 소스 제어 연결을 공유 할 수있는 프로젝트 / 솔루션 파일을 결정하는 데 사용됩니다. 공간에 대한 이스케이프 규칙이 솔루션 및 프로젝트 파일에서 다르기 때문에이 이름에 공간을 사용하지 않는 것이 좋습니다.
   • SccProvider0 : 하드 코딩 된 값 "MSSCCI : Perforce \ u0020SCM".
7. 선택한 Perforce 클라이언트 (p4.exe, P4Win, P4V)를 사용하여 두 개의 보류중인 파일을 제출합니다.

이제 바인딩을 테스트 할 수 있습니다.

1. Visual Studio가 닫혀 있는지 확인
2. name.sln (특히 name.suo)을 제외한 ** 모든 * 파일 삭제
3. Visual Studio를 열고이를 사용하여 name.sln을 엽니 다.
4. 연결 대화 상자가 나타나면 적절한 포트 / 클라이언트 / 사용자를 사용하고 확인을 클릭합니다.
5. 이제 솔루션 탐색기에 자물쇠 오버레이 아이콘이있는 솔루션 노드가 표시됩니다.
6. 이제 "파일"-> "소스 제어"-> "소스 제어 변경 ..."을 사용하여 솔루션의 소스 제어 상태를 확인할 수 있습니다. 참고 : "서버 바인딩"열에는 "SccProjectName0"에 대해 선택한 값이 표시됩니다. .

소스 제어 새 프로젝트

새로운 프로젝트를 만들고 Perforce 저장소에서 즉시 추적을 시작하려면 다음 단계를 따르십시오.

1. Visual Studio에서 소스 제어 솔루션 열기
2. "파일"-> "추가"-> "새 프로젝트 ..."-추가 할 프로젝트 유형, 이름 및 위치를 선택합니다 (위치는 솔루션 파일이 저장된 디렉토리의 하위 디렉토리 여야 함).
3. "파일"-> "모두 저장"(이렇게하면 솔루션 파일의 모든 메모리 내 변경 사항과 새로 생성 된 프로젝트 파일이 디스크에 커밋됩니다)

4. 선택한 편집기를 사용하여 방금 만든 프로젝트 파일을 수동으로 편집합니다 (어서, 메모장 다시 시작? ;-)). 다음 속성 요소를 PropertyGroup (모든 속성 그룹)에 추가합니다.

   <PropertyGroup>
       ...
       <SccProjectName>Tutorial</SccProjectName>
       <SccLocalPath>..\..</SccLocalPath>
       <SccProvider>MSSCCI:Perforce SCM</SccProvider>
       ...
   </PropertyGroup>
   

   값은 다음과 같이 선택해야합니다.

   • SccProjectName- "소스 제어 변경"대화창에 "서버 바인딩"으로 표시되는 값입니다. 빈 솔루션에서 SccProjectName0에 사용한 값과 동일해야합니다. 동일하지 않은 경우 솔루션과이 프로젝트는 동일한 소스 제어 공급자 연결을 공유 할 수 없습니다.
   • SccLocalPath- 참조 디렉토리에 대한 상대 경로 ( "소스 제어 변경"대화 상자에 "로컬 바인딩"으로 표시됨); 솔루션 디렉터리를 참조 디렉터리로 사용하는 것이 좋기 때문에 이것은 사실상 프로젝트 파일이 포함 된 디렉터리에서 솔루션 파일이 포함 된 디렉터리까지의 상대 경로입니다 (제 예는 "(solutionDir) /Source/ProjectName/projectName.csproj"에 프로젝트를 저장하는 것입니다. 상대 경로는 "2 단계 위로"입니다.)
   • SccProvider- 하드 코딩 된 값 "MSSCCI : Perforce SCM"; Scc * 바인딩 값이 유효한 SCCAPI 공급자를 결정하는 데 사용됩니다.

5. Visual Studio로 다시 전환하십시오. 프로젝트 파일이 외부에서 업데이트되었음을 ​​자동으로 감지하고 다시로드하도록 제안해야합니다 (그렇지 않은 경우 프로젝트를 수동으로 언로드하고 다시로드).

6. "보기"-> "보류중인 체크인"
7. "체크인"-> (solutionName) .vssscc 파일을 마우스 오른쪽 버튼으로 클릭하고 "변경되지 않은 경우 되돌리기"를 선택하는 것이 좋습니다 (Visual Studio가 편집을 위해 열어도 변경되지 않은 상태로 유지됨); 설명 제공 및 변경 사항 제출

새로 추가 된 프로젝트가 올바르게 바인딩되었는지 확인하려면 다음 단계를 수행하십시오.

1. Visual Studio가 닫혀 있는지 확인
2. (solutionName) .suo 파일과 MSSCCPRJ.SCC (솔루션 디렉토리에서) 삭제
3. Visual Studio를 열고 사용하여 (solutionName) .sln을 엽니 다.
4. 연결 대화 상자가 나타나면 적절한 포트 / 클라이언트 / 사용자를 사용하고 확인을 클릭합니다.
5. 이제 솔루션 탐색기에 자물쇠 오버레이 아이콘이있는 프로젝트 노드가 표시됩니다.

6. 이제 "파일"-> "소스 제어"-> "소스 제어 변경 ..."을 사용하여 솔루션의 소스 제어 상태를 확인할 수 있습니다.

   이 상태 스크린 샷에 대해 주목할 점은 솔루션 행을 선택했을 때 나머지 모든 행도 "선택"되었다는 것입니다 (파란색 강조 표시). 이는 모든 항목이 동일한 "서버 바인딩"+ "로컬 바인딩"을 가지므로 동일한 소스 제어 공급자 (P4) 연결을 공유하기 때문입니다.

   또한 두 프로젝트의 "상대 경로"에는 두 가지 수준이 있으며 동일한 "로컬 바인딩"(솔루션 파일이있는 디렉터리)에 상대적입니다.

소스 제어 기존 (언 바운드) 프로젝트

다른 Perforce 솔루션에서 아직 사용되지 않은 기존 프로젝트가있는 경우 다음 단계에 따라 Perforce에 추가합니다 (예 : 이전에 소스 제어되지 않은 프로젝트 (인터넷 다운로드 등) 또는 다른 소스 제어를 사용하는 프로젝트 가져 오기). 공급자 (Visual Source Safe 등).

1. 프로젝트를 적절한 위치에 복사
2. 기존 소스 제어 바인딩 정리 (있는 경우) :
   • 기존 프로젝트 파일 바인딩, 즉 "Scc"로 시작하는 모든 속성을 제거합니다.
   • 프로젝트 파일 (있는 경우)과 동일한 디렉토리에서 파일 (projectName) .vspscc를 삭제합니다.
3. Visual Studio에서 소스 제어 솔루션 열기
4. "파일"-> "추가"-> "기존 프로젝트 ..."-프로젝트를 찾습니다 (1 단계에서 만든 복사본).
5. "파일"-> "모두 저장"(이렇게하면 메모리 내 모든 변경 사항이 솔루션 파일에 적용됨)
6. "소스 제어 새 프로젝트"의 4-7 단계를 따르십시오 (즉, "Scc *"속성 요소를 PropertyGroup에 추가합니다 ).

확인 단계는 "새 프로젝트 소스 제어"섹션과 정확히 동일합니다.

소스 제어 기존 (바운드) 프로젝트

여기에 설명 된 기술을 사용하여 Perforce에 이미 바인딩 된 프로젝트가 있고 다른 솔루션 (새 분기, 프로젝트를 재사용하는 대체 솔루션 등)에서 사용하려는 경우 다음 단계를 사용하십시오.

1. 프로젝트를 원하는 위치에 통합
2. Visual Studio에서 소스 제어 솔루션 열기
3. "파일"-> "추가"-> "기존 프로젝트 ..."-통합을 통해 1 단계에서 만든 프로젝트를 찾습니다.
4. "보기"-> "보류중인 체크인"-> "체크인"-설명 추가 및 제출

요약

• 소스 제어 바인딩 정보는 솔루션과 프로젝트 모두에 저장되며 동기화되어 있어야합니다 (그렇지 않은 경우 Visual Studio에서 불일치를 수정하려고 시도 함).
• 저는 항상 프로젝트 파일을 바인딩 정보의 기본 소스로 취급하고 솔루션 파일은 먼저 빈 솔루션을 소스 제어 한 다음 원하는 프로젝트를 추가하여 쉽게 다시 만들 수있는 일회용 파일로 취급합니다.
• 솔루션 파일에는 항상 유효한 SccProvider0 및 SccProjectName0 값이 있어야합니다 (새 버전의 P4SCC 플러그인에서 수동으로 추가해야 함).
• 프로젝트 파일은 항상 유효해야 SccProjectName (같은 양호하게는 같은 SccProjectName0을 ), SccLocalPath 및 SccProvider 값합니다 (P4SCC 기본적으로 더 좋은 없기 때문에 수동으로 편집 할 수 있습니다)

원래 질문에 대한 답변도 포함했습니다.

"소스 제어 변경"을 수행하고 프로젝트를 바인드하면 어떻게됩니까? Visual Studio는 프로젝트 및 솔루션 파일에 넣을 내용을 어떻게 결정합니까?

이렇게하면 리 바인딩중인 프로젝트 파일의 "Scc *"요소가 업데이트됩니다. 그런 다음 솔루션 파일도 업데이트되어 프로젝트 파일 바인딩과 동기화됩니다.

"소스 제어에서 열기"를 수행하면 어떻게됩니까?

Allows you to pick solution that you'd like to open. Afterwards all the projects included in the solution are automatically synced to head. I find this feature not very useful in Perforce world where you have to create a client anyway and the chances are you're syncing this client from a P4V/P4Win/P4 instead of relying on Visual Studio. This was kind-of useful in Visual Source Safe world where there was no concept of views and you were defining where a repository goes on checkout time.

What's this "connection" folder that SccLocalPath and SccProjectFilePathRelativizedFromConnection refer to? How does Visual Studio/Perforce pick it?

This is Visual Studio's bookkeeping. It is determined based on bindings in each project file (I guess in theory if a project file loses binding information for some reason, it could be reconstructed from the solution information...)

Is there some recommended way to make the source control bindings continue to work even when you create a new branch of the solution?

I hope the sections above give you some idea of a way that is working very well for me :-).

---

Milan's post is well-researched and well-written, but its length demonstrates beyond a shadow of a doubt that the P4SCC model is broken. Storing source control binding info inside the project & solution files is ridiculous. Enforcing (via sccprojectname) that a project be part of only one solution is equally ridiculous.

Additionally, P4SCC has a tremendous performance cost in a large solution, as it retrieves info from source control for each file at startup, and maintains that state in memory throughout the development session. It creates extra cruft in the form of information-free .vsscc & vssscc files to support some SCC feature that (AFAICT) Perforce does not use.

The ideal Perforce integration looks like:

• If I create a new solution, project, or project item, run 'p4 add'.
• If I change a file, run 'p4 edit'.
• Some toolbar/context menu integration for revision history, revision graph, timelapse/blame, and 'show in P4 gui'.
• (nice to have) If I rename a file that exists in the depot, run 'p4 integrate' and 'p4 delete'. If I rename a file opened for add, run 'p4 revert' and 'p4 add'.
• That's all

We have moved completely away from P4SCC and its bizarre requirements and burdens. Instead we use NiftyPerforce. There are some bugs, but we find working around these bugs to be much less frustrating than working around the design defects in the Perforce<->VSSCC model.

---

Just to keep this current - the P4VS plugin has been rewritten circa 2012

Now you can perform all of your daily interaction with Perforce naturally, like checking in code and viewing file history, directly from the IDE.

If you’re a power user looking for a bit more, P4VS won’t disappoint. P4VS is fully compatible with Perforce Streams, and the Stream Graph is accessible from the IDE, along with Time-lapse View and Revision Graph. If you are responsible for branch management, you can merge from P4VS as well.

And, if you work remotely or want to do a little private branching, P4Sandbox can be configured through P4VS.

• P4VS page on perforce.com
• Webinar on how to use it

---

Using Perforce with Visual Studio can be simplified by using the P4CONFIG environment variable.

Basically you go into Visual Studio, Tools -> Options -> Source Control -> Plug-in Settings, Advanced button. This will bring up a Perforce configuration dialog specific to the SCC integration. Switch to the Connection tab, and check the radio button titled 'Bind the workspace that matches your Perforce environment settings'. This will tell perforce to prefer using P4CONFIG environment variable for determining the environment you are under. This same dialog exists in P4V under Edit -> Preferences, but only affects p4v's behavior.

How you setup the P4CONFIG environment variable is up to you to some degree. I like having them be named the same everywhere so I set a system-wide environment variable P4CONFIG to look for a file named p4config.cfg. This file is just an ini style file, where you can assign other variables such as P4USER, P4CLIENT, P4HOST etc. Perforce will search for this file in the current directory and all parent directories until it encounters one. Basically you put this file in the root most directory of your where your clientspec is mapped to on your hard drive, and leave it alone.

This approach greatly reduces the amount of 'correctness' that the SCC configuration needs in visual studio in order to function. (SAK bindings work fine etc.)

If after syncing your code from perforce for the first time or to a totaly clean directory structure, and getting a dialog complaining about perforce wanting to either temporarily work offline or remove bindings, there is still some editing you need to do. Primarily the .sln file itself needs to be modified so it knows the sln has SCC bindings for itself . This is done by making sure the following fields are placed right after SccNumberOfProjects in the .sln file.

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

All of the individual projects should work fine with default 'SAK bindings' provided you are using the P4CONFIG approach. Fixing this should allow Perforce to work from a clean sync perfectly, and also eliminate the generation of MSSCCPRJ.SCC cruft in each of the project directories.

---

Support for renaming a file or moving it to a new folder directory is terrible and painful if using the Visual Studio P4 plug-in integration. No built-in feature exists that alerts P4 to renaming the file or that it has been moved.

The issue is that renaming a file requires not just updating the associated VS project file but Perforce needs to be informed as well of the change if you want to maintain proper revision history.

Currently, I do not see a way to do both in a single operation if using the VS integration. Instead, you have to:

1. rename/move the file from within the Perforce client
2. delete the old filename reference in the project file within VS
3. add the new filename reference in the project file within VS
4. submit your changes

If you use a continuous integration build process and you submit changes at any point prior to the last step, you are guaranteed to have a broken build.

The problem magnifies significantly the more files that require renaming or moving. This is not a smooth process whatsoever.

---

After experimenting with Milan Gardian's very informative answer, I think I can provide a simpler solution to get it working pretty well.

As Weeble mentioned, the SAK values work fine when everything else is set up correctly, and they are often the default values (but I think it depends on which project type it is). If they do not show up in your project, just paste in this property group.

<PropertyGroup>
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>

Add these two lines to the *.sln in the SourceCodeControl GlobalSection. As long as the project files have SAK values, they should inherit the names from the solution.

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

No *.vssscc, *.vspscc, or *.SCC files need to be checked in (though they will be generated when the solution is opened).

---

Very poorly. I know that is not the answer to your questions that you were looking for (in the future, perhaps you could narrow the focus?), but source control integration with Visual Studio just sucks. The reason being that they all have to use Microsoft's terrible SCC interface. It's pathetic! They put source control information in the project files! Why would they do that?

Just abandon the Visual Studio integration and use the Perforce client. It's not that much extra work. You can't spare 30 seconds per day to switch over to the Perforce client and check in/out the files out from there?

---

I can answer the last one.

In order to get source control bindings to work even when you create a new branch, follow a strict hierarchical structure:

/Solution
  /library1
  /library2
  /product1
  /product2
  /subsolution
    /sublibrary1
    /subproduct1

Each file must be in exactly one .vcproj. You can have multiple .vcproj in the same directory, but if they share files, the shared files must go into their own .vcproj.

If you are relentless in this, all the Scc stuff will be relative-path, so a new branch will work (because it only changes the topmost directory).

---

This is not a Perforce issue, it is a Visual Studio issue. The ridiculous requirement that source files be modified to allow Visual Studio to understand that there is an SCM tool in use is idiotic.

The simple answer is 'stop using the Visual Studio source control integration'. It just plain sucks. Even with TFS it just plain sucks.

Visual Studio 내에서 체크 아웃 할 수 있도록하려면 사용자 지정 도구를 만들기 만하면됩니다. 적절한 VS 변수를 사용하여 'p4 edit'에 대한 간단한 호출 만 있으면됩니다. 파일을 되 돌리시겠습니까? 같은 생각 ... 적절한 변수로 p4 되돌리기를 호출하십시오. 끝난.

p4v를 사용하여 소스 제어 요구 사항 (제출, 기록, 차이점 등)을 관리합니다. Visual Studio는 소스 편집기로 사용됩니다. 그것은 SCM 인터페이스로 짜증납니다.

참고 URL : https://stackoverflow.com/questions/261525/how-does-visual-studios-source-control-integration-work-with-perforce