RE: Source Safe Visual Studio bindings incorrect after Share and B

Thank you for your reply. I don’t see the dialog possibly because I get the
latest version from the new branch so it is easy for the incorrect bindings
to go unnoticed. What I have noticed is that the problem appears to occur
only for some solutions while others appear to bind to the new branch. If I
look in the SLN file I notice that for the projects that retain the old
binding the SCC settings are different. For those solutions that have the
correct bindings there is a setting
SccProjectFilePathRelativizedFromConnectionn where n is an integer starting
at 1 there are 1 less of these settings than thee are projects in the
solution. Below are excerpts from two SLN files. As you can see in the later
case the bindings have a full path while the first case appears to be a
relative path.

How can we get all the SNL files to bind in the same way, preferably with
relative paths?

This is a section of a SLN that the bindings appear to follow the new branch

GlobalSection(SourceCodeControl) = preSolution

SccNumberOfProjects = 4

SccLocalPath0 = .

SccProjectUniqueName1 = FilePurge\\PurgeEngine.csproj

SccLocalPath1 = .

SccProjectFilePathRelativizedFromConnection1 =
FilePurge\\

SccProjectUniqueName2 =
ICPurgeService\\ICPurgeService.csproj

SccLocalPath2 = .

SccProjectFilePathRelativizedFromConnection2 =
ICPurgeService\\

SccProjectUniqueName3 =
PurgeServiceTester\\PurgeServiceTester.csproj

SccLocalPath3 = .

SccProjectFilePathRelativizedFromConnection3 =
PurgeServiceTester\\

EndGlobalSection.



This is a section from a SLN that points back k to the original branch



GlobalSection(SourceCodeControl) = preSolution

SccNumberOfProjects = 6

SccLocalPath0 = .

SccProjectUniqueName1 = MFPTester\\MFPTester.csproj

SccProjectName1 =
\u0022$/IntelliChief/Ver2_3/Ver2_3_0/Server/Windows/Services/ICMfpFolderMonitoringService/MFPTester\u0022,\u0020DTJVAAAA

SccLocalPath1 = MFPTester

SccProjectUniqueName2 =
...\\ServicesCommon\\ICFolderMonitorBatchProcessor\\ICFolderMonitoringBatchProcessor.csproj

SccProjectName2 =
\u0022$/IntelliChief/Ver2_3/Ver2_3_0/Server/Windows/Services/ServicesCommon/ICFolderMonitorBatchProcessor\u0022,\u0020GJKVAAAA

SccLocalPath2 =
...\\ServicesCommon\\ICFolderMonitorBatchProcessor

SccProjectUniqueName3 =
...\\ServicesCommon\\IcFolderMonitoringDatabase\\ICFolderMonitoringDatabase.csproj

SccProjectName3 =
\u0022$/IntelliChief/Ver2_3/Ver2_3_0/Server/Windows/Services/ServicesCommon/IcFolderMonitoringDatabase\u0022,\u0020OJKVAAAA

SccLocalPath3 =
...\\ServicesCommon\\IcFolderMonitoringDatabase

SccProjectUniqueName4 =
ICFolderMonitoringEngine\\IcMfpFolderMonitoringEngine.csproj

SccProjectName4 =
\u0022$/IntelliChief/Ver2_3/Ver2_3_0/Server/Windows/Services/ICMfpFolderMonitoringService/ICFolderMonitoringEngine\u0022,\u0020ESJVAAAA

SccLocalPath4 = ICFolderMonitoringEngine

SccProjectUniqueName5 =
ICFolderMonitoringService\\IcMfpFolderMonitoringService.csproj

SccProjectName5 =
\u0022$/IntelliChief/Ver2_3/Ver2_3_0/Server/Windows/Services/ICMfpFolderMonitoringService/ICFolderMonitoringService\u0022,\u0020NSJVAAAA

SccLocalPath5 = ICFolderMonitoringService

EndGlobalSection

Thanks
QSI



"WenYuan Wang [MSFT]" wrote:

Hello QSIDeveloper,

According to your description, you found an issue that the solution still
binds to the original SS project tree after you performed a Share/Branch on
it. If I misunderstood anything here, please don't hesitate to correct me.

How do you open the solution in VS 2005? If you open it by
"File|Open|Project|SourceSafe", I believe you must have gotten a dialog as
below:
"You opened a project or solution from a location that doens not machtch
its original server binding. The project or solution may have been branched
in your source control store..."

The binding information is stored in .sln file. VSS doesn't know about it.
Therefore, after you share/branch the project, the binding information
which is stored in .sln file doesn't change. It still indicates to the
original SS project tree. This is the reason why you face the issue that
project binds to the "wrong" SS project.

To resolve this issue, you would have to re-bind your solution after
sharing/Brach it in VSS. You can re-bind the project to CORRECT VSS project
tree by "File|SourceControl|Change SourceControl".

Hope this helps. Let me know if you have any more concern. We are glad to
assist you.

Have a great day,
Best regards,

Wen Yuan
Microsoft Online Community Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.


.

Relevant Pages

  • Re: cpuset and affinity implementation
    ... An example would be some sort of system with multiple CPUs where some ... So if you just make a set that includes all cpus in the system you can then bind your realtime threads to specific cpus and the other threads to the remainder. ... The reason individual threads can't be assigned to groups is because cpuset_getidfor a pid wouldn't make sense then and I expect administrators to be mostly interested in managing groups of processes. ... bindings when returning the processor set for the process. ...
    (freebsd-arch)
  • Re: Recovering keys from key events
    ... bind the key events that correspond to these actions, ... other bindings flow through. ... This is exactly how Leo works. ... making a unique callback for every binding. ...
    (comp.lang.tcl)
  • Re: Binding to menu entry - not just to menu(-tree)
    ... bindings "quite safely"? ... bind .menubar.help.menu ... tag. ... and use helptext() lookup instead of most ...
    (comp.lang.tcl)
  • Re: Tktable question
    ... was doing for bindings and asked why, ... bind Table ... virtual events, but the lack of double angle braces (in other words, ... place the data into the appropriate buffer? ...
    (comp.lang.tcl)
  • VSS2005: How to export files
    ... How do I export the files of a project *without* exporting the vss ... All I want is to get my source files out of vss with no *.scc, ... bindings in my VS.NET project files. ...
    (microsoft.public.vstudio.sourcesafe)