Perforce problem in Visual Studios 2008
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 WITHOUT checking to make sure it is the current version. Is there a way to get Visual Studios to get the latest version of the file before it is checked out?
We usually determine that this happened after the files went missing in Visual Studios. Here's what usually happens:
- User A adds a file to the project.
- User A checks out both the project and the new file.
- User B checks out the project without getting the latest version
- User B adds a file.
- User B checks out both the project and the new file.
- User A gets the latest project definition and notices that his file is "missing".
As a preventative measure, I require my team members to get a new project definition immediately before adding files. Despite this precaution, errors continue to occur and files "disappear". While we can manually extract them from Perforce and add them back to the project definition, we don't have to go through this pain at all. I know Perforce can automatically detect changes in files. Perforce automatically compares your local copy to the server version and replaces the local version if it detects a difference when you choose to undo. There must be a way to force it to check for GOOD until it is removed like VSS. It's sad when my developers tell me they want to go back to VSS.
a source to share
This can be a problem with the "generic" workspace client used with P4SCC and Visual Studio. Workspace clients must be unique for each user and machine. Perforce uses a workspace client to track the contents of a specific workspace on a computer.
Here's how it happens when both users are using the same workspace client:
-
Both users A and B are forced to sync with the latest changes using the "standard_1" client. The table is updated on the server, noting that project "foo" is in revision # 12.
-
User B checks out "foo", adds a file, and submits. The table has now been updated to note that project "foo" is in revision # 13 in standard_1 workspace.
-
User A now checks out project "foo", adds the file, and uploads - no conflict - as revision # 14 to standard_1 workspace, because Perforce thinks the 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 split the availability lists for each user's workspace, and the change and conflict warning on checkout will work every time.