If you install Visual Studio 2003 after you install Perforce 2004.2 you will not have access to Perforce’s source control provider until you change HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\ProviderRegKey from “Software\Microsoft\SourceSafe” to “SOFTWARE\Perforce\P4”.
More thoughts on Perforce labeling.
When you create a label, you should do it in the following steps:
1. Create a new label.
2. Restrict the label to a set of folders and files you expect will always be in future versions of the label. Do this by selecting folders (and files) in the depot view, dragging them to the label, and choosing "Add Depot Selections to View for ...." (make sure you delete the original filter).
3. Now you can drag the entire depot to the label and choose "Add/replace files listed in..."
The big benefit of doing it this way is when you release the next version of the product. You create the new label using the old one as a template; drag the whole depot to it, and you're done... It helps to avoid those situations where there's a little used dependency between projects that you might otherwise forget to include in the label.
I first noticed this problem with the beta version of
2003.2 P4SCC and now suspect it’s a configuration problem peculiar to my setup.
I am unable to check files in from Visual Studio .NET 2003. I can view pending checkins normally, but when I click “Check In”, I get this dialog box with all controls disabled except the close box.
What should be happening and why might this be happening?
Spent entirely too much time today figuring out why Visual Studio .NET 2003 solutions sometimes get wedged in a "some of the properties associated with the solution could not be read" state.
The solutions appear to be okay otherwise, but each time they are opened, you get the error message.
The problem is introduced when projects are added to the solution. I’ve observed it with web application projects already under Perforce source control.
The solution file (.sln) will have a SccNumberOfProjects value greater than the actual number of projects and there will be duplicates of some projects. The duplicates are typically missing the SccProjectFilePathRelativizedFromConnection# property.
To fix the problem (or at least to get rid of the error message):
1. Adjust the SccNumberOfProjects property value to the expected number.
2. Delete duplicate SourceCodeControl information. The usual sequence of properties is something like:
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 11
SccProjectName0 = Perforce\u0020Project
SccLocalPath0 = .
SccProvider0 = MSSCCI:Perforce\u0020SCM
CanCheckoutShared = true
SolutionUniqueID = {A0C7BB98-83C3-491B-9A97-CDE906E50E22}
SccProjectUniqueName1 = http://localhost/jq/h/JobQuake\u0020Help.csproj
SccLocalPath1 = JobQuake\u0020Help
CanCheckoutShared = true
SccProjectFilePathRelativizedFromConnection1 = http://localhost/jq/h
SccProjectUniqueName2 = http://localhost/jq/a/JobQuake\u0020Admin.csproj
SccLocalPath2 = JobQuake\u0020Admin
CanCheckoutShared = true
SccProjectFilePathRelativizedFromConnection2 = http://localhost/jq/a
3. Adjust the trailing indices on SccProjectUniqueName, SccLocalPath, and SccProjectFilePathRelativizedFromConnection to run from 1 to SccNumberOfProjects, inclusive.
The “View:” description of a label spec looks like:
//depot/Tone/kzDev/VSP/...
"-//depot/Tone/kzDev/VSP/3rd Party/..."
"-//depot/Tone/kzDev/VSP/AppointMed/..."
Quotes are needed if the path contains a space.
Hyphen excludes the path.
Once the label has been created and the path filters specified, specific file versions falling within the filter must be added to the label.
View:
"//depot/Tone/kzDev/VSP/Job Blaster/..."
"//depot/Tone/kzDev/VSP/JobQuake Admin/..."
//depot/Tone/kzDev/VSP/Spider/...
//depot/Tone/kzDev/VSP/HttpHtmlToXml/...
//depot/Tone/kzDev/VSP/DataGridColumnStyles/...
//depot/Tone/kzDev/VSP/Geography/...
//depot/Tone/kzDev/VSP/Resources/...
//depot/Tone/kzDev/VSP/SiteMonitor/...
//depot/Tone/kzDev/VSP/Utility/...
//depot/Tone/kzDev/VSP/WebUtility/...
"//depot/Tone/kzDev/VSP/ActiveX References/..."
//depot/Inetpub/wwwroot/Services/JobBlasterServices/...
//depot/Inetpub/wwwroot/jqa/...
//depot/Inetpub/wwwroot/WebUtility
To recursively check in file in Perforce, wrote the following python script called kzP4Add.py
import os, sys
def visit(arg, dirname, names):
for n in names:
r = os.spawnl(os.P_WAIT, r"C:\Program Files\Perforce\p4.exe", r"p4", "add", '"'+os.path.join(dirname, n)+'"')
print r, dirname, n
def Main():
if len(sys.argv) != 2:
print "Usage is kzP4Add "
for a in sys.argv: print a
return
absdir = os.path.abspath(sys.argv[1])
os.path.walk(absdir, visit, 0)
if __name__ == "__main__":
Main()
Its key that the first argument is the program name, excluding the path info.
Adding the quotes around the filename argument is necessary if the path or name can contain spaces.
The client doesn’t need to be specified.
1. Much safer to create a new project and delete the old than it is to rename it.
2. If Visual Studio won’t do the checkin, see if the change list can be submitted manually from p4win.
3. Don’t forget to delete web projects in Intenet Information Systems manager after removing them from a project & from perforce.
4. If a Web Application or Web Service project won’t load into Visual Studio, it may need to have its Directory properly configured in IIS. Check that Server Extensions are installed and Properties->directory->Application Settings->Create.
Spent one intermittent day on a source control solution. Had to be free and fully integrated with dotNET which left two options I knew about: Perforce and SourceSafe.
I had confidence in the quality of Perforce but was/am concerned about its integration with web projects. Specifically, it can’t checkin files unless they appear (in active use by VS) within the subtree anchored by P4ROOT. This leads to the root being “c:\” so that it captures both “c:\inetpub” and my normal development folders under “c:\tone”. I suspect this may get ugly when/if branches are needed. I have half a hope that client specs can be used to help.
Not a complete solution yet. Can’t checkin web projects that aren’t rooted on “http://localhost”.
Perforce uninstall works quickly and leaves the database and depot files behind.
Perforce install grabs the value of P4ROOT from the environment and removes the variable. It becomes the depot root and the suggested location for the server installation, which can be changed manually during installation without affecting the depot root. A bit weird. I’m probably missing something.
Because of the “c:\” depot root inflexibility, I backed out of Perforce a few times.
Trying Visual Source Safe 6.0c rapidly brought back all the bad memories associated with it. Bad interface. Cryptic database. Puzzling semantics.
Let’s hope for the best.
On the plus side, I can now use Perforce to version any file on my hard disk!