[p4] Perforce integration with VS .NET 2003

[Andy Finkenstadt]

I think all of us that use the P4SCC plug-in have come to workable terms 
with it and learned what to do or not to do with it in our own environments.

Our environment here is Visual Studio 2003 & 2005 on windows, with 
perforce server 2005.2 on linux and perforce client 2005.2 and 2006.1.  
We have many, many solutions, some of which have upwards of 50 projects 
and some few thousand files in it.

We've learned that case-sensitivity on the server matters, when it comes 
to Visual Studio's automatic checking of the files in the solutions for 
presence in source-code control.  An upper-case directory on one client 
and a lower-cased directory on another client which are otherwise "the 
same" will cause VS to mark one or the other as "newly added content".  
We now have a trigger on the server which enforces our policy of uniform 
caseness in directory names.  (I'm pretty sure the same applies to file 
names, but those are more easily kept in sync on the clients.)

We've learned that when you add a file to a project, if you do it from 
within the Visual Studio IDE, you need to press the "Check-in Files..." 
button at least once from the Pending Checkins window in order to get 
VS-IDE and Perforce workspace "in sync".  We usually just Esc/Cancel the 
resulting dialogs.  Alternatively one can use perforce (p4, p4win, p4v) 
to add the file to the depot after adding it to the project file, but 
the IDE will still be out of sync with regard to the file's source-code 
control status.

We've learned that the check-in "change description" box that appears 
from within the IDE is sometimes missing checkmarks on the newly added 
files when you go to check in changes related to a project.  Grrr...  so 
we just have to remember to re-check those boxes.

We've learned that the first time we open up any solution in a client 
workspace, Visual Studio wants to establish SCC bindings in the solution 
options file (a hidden blah.suo next to the blah.sln file).  Sometimes 
this works, sometimes not.  We usually choose to work "totally removed" 
and then go to File->Source Control->Change Source Control, and bind to 
the right client workspace name.  VS will think that it needs to 
check-out the project files.  Let it.  When it has finished doing its 
thing, File->SaveAll, and then go to p4/p4win and revert unchanged 
files.  That will be all of the project files, usually. 

We've also learned to go with project bindings and not solution 
bindings, since some of our solutions use projects from "other" 
directories.  Visual Studio warns against it, sometimes, but this seems 
to work just fine.

We learned that having incompatible versions of the client-side P4SCC 
causes "source code control binding tugs-of-war".  Once we got all 
developers up to the same install (2005.2/92367 or so) we stopped having 
check-ins related to those "changed" bindings.  I only recently learned 
that 2006.1 P4SCC is also compatible with 2005.2.  I don't yet know for 
2006.2 P4SCC.

There are likely other things that we have learned, but this is what I 
remember so far.

--andy
 Simutronics Corp.


James Lavery wrote:
> Hi Nir,
> We've got a solution with 48 (yes, 48!) projects in it, and it works
> fine, with several people in a team working on it.
>