Perforce Issue in Visual Studios 2008

Question

My team uses Visual Studios 2008 to develop SSIS packages and we use Perforce as our source control system. When a user adds a file to a project, the project is automatically checked out WITHOUT checking to see if it is the current version. Is there a way to force Visual Studios to get the latest version of a file before it is checked out?

We usually determine this happened after files go "missing" in Visual Studios. Here's what usually happens:

1. User A adds a file to the project.
2. User A checks in both the project and the new file.
3. User B checks out the project without getting the latest version
4. User B adds a file.
5. User B checks in both the project and the new file.
6. User A gets the latest project definition and notices their file is "missing".

As a preventative measure I require my team members to get the latest project definition immediately before adding files. Despite this precaution, mistakes continue to happen and the files "disappear". Although we can retrieve them from Perforce manually and add them back to the project definition, we shouldn't have to go through this pain at all. I know Perforce can detect changes to files automatically. Perforce will automatically compare your local copy to the server version and replace the local version if it detects a difference when you select undo check-out. There has to be a way to force it to check BEFORE it allows the file to be checked-out like VSS. It's sad when my developers tell me they WANT to go back to VSS.

Answer 1

This could be an issue with a "shared" workspace client being used with P4SCC and Visual Studio. Workspace clients should be unique to each user and machine -- Perforce uses the workspace client to track the contents of a specific machine's workspace.

Here's how it happens when both users are using the same workspace client:

• Both Users A and B force sync to the latest revisions using the "standard_1" client. The have table is updated on the server, noting that project "foo" is at revision #12.

• User B checks out "foo", adds a file, and submits. Now the have table is updated and notes that project "foo" is at revision #13 in the standard_1 workspace.

• User A now checks out project "foo", adds a file, and submits -- without a conflict -- as revision #14 in the standard_1 workspace, because Perforce thinks that workspace already has #13.

The solution is to confirm that each user has a workspace client specification that is unique to their machine. This will separate the have lists for each user workspace, and the warning on edit and conflict on checking in will work every time.