How does Visual Studio's source control integration work with Perforce?

Question

We're using Perforce and Visual Studio. Whenever we create a branch, some projects will not be bound to source control unless we use "Open from Source Control", but other projects work regardless. From my investigations, I know some of the things involved:

In our .csproj files, there are these settings:

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

Sometimes they are all set to "SAK", sometimes not. It seems things are more likely to work if these say "SAK".

In our .sln file, there are settings for many of the projects:

• SccLocalPath#
• SccProjectFilePathRelativizedFromConnection#
• SccProjectUniqueName#

(The # is a number that identifies each project.) SccLocalPath is a path relative to the solution file. Often it is ".", sometimes it is the folder that the project is in, and sometimes it is ".." or "..\..", and it seems to be bad for it to point to a folder above the solution folder. The relativized one is a path from that folder to the project file. It will be missing entirely if SccLocalPath points to the project's folder. If the SccLocalPath has ".." in it, this path might include folder names that are not the same between branches, which I think causes problems.

So, to finally get to the specifics I'd like to know:

• What happens when you do "Change source control" and bind projects? How does Visual Studio decide what to put in the project and solution files?
• What happens when you do "Open from source control"?
• What's this "connection" folder that SccLocalPath and SccProjectFilePathRelativizedFromConnection refer to? How does Visual Studio/Perforce pick it?
• Is there some recommended way to make the source control bindings continue to work even when you create a new branch of the solution?

Answer 1

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).

Answer 2

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?

Answer 3

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.

Answer 4

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.