Some tips about using the VSS Plugin. When I first configured it, I was seeing t...
Some tips about using the VSS Plugin.
When I first configured it, I was seeing the text 'Started...' on the Console Output. It took me a while to realize that this was due to the VSS 'getHistory' and 'checkOut' taking about 20-30 minutes. When it is doing the 'getHistory' there appears to be no visible feedback (either on the console output or on the file system). After about 10 minutes, when it starts checking out (getting) the files from VSS, the file system (workspace) starts getting refreshed. As far as I could tell that's the only feedback available.
In case any one else runs into issues with the configuration, I thought I would post some more details about the configuration ...
1. Server Path - provide the path to the srcsafe.ini file. This is usually the same network path mapping that you would do on your VSS client. Example - \\serverName\path\srcsafe.ini
2. VSS Folder Path - provide the path from the VSS Project Root. Example - $/ProjectRoot
3. Keep files as writable - I would recommend keeping this checked especially for .Net projects. In my case, I was using an Nant solution task to build a .Net project, relying on the same .sln & .csproj file used by developers (& checked in to VSS). The developers had custom PostBuildEvents configured in the .csproj files that were conflicting with the automated build ... by keeping the files as writable, I was able to xmlpoke and manipulate the PostBuildEvents.
4. Use Update - KEEP THIS UNCHECKED ALWAYS. When running .Net builds with this option checked, I found that compile errors would go unreported sometimes ... this was because some dependencies would be omitted by the compiler in the compile step as their assemblies (dlls) were already available. Keeping this unchecked slows down the build (get from VSS), but it is worth it.
Other issues -
I could not figure out how to setup the VSS Plugin on a Windows 2003 server that had Hudson configured as a service. The problem is that when Windows starts Tomcat as a service (I am running Hudson under Tomcat), the service is started by 'System'. There is no Network mapping available to the VSS share. The 'get' from VSS fails in this case.
I tried to start the service using a logon id, but even that didn't work.
I finally gave up and I am working around by having a logon startup .bat script to map the network drive to VSS + start Tomcat / Hudson. And I keep the logon session active always. It sucks, but that is the only setup I could get it working.
Visual SourceSafe Plugin
Comments (1)
Jul 02
Mahesh Narayanan says:
Some tips about using the VSS Plugin. When I first configured it, I was seeing t...Some tips about using the VSS Plugin.
When I first configured it, I was seeing the text 'Started...' on the Console Output. It took me a while to realize that this was due to the VSS 'getHistory' and 'checkOut' taking about 20-30 minutes. When it is doing the 'getHistory' there appears to be no visible feedback (either on the console output or on the file system). After about 10 minutes, when it starts checking out (getting) the files from VSS, the file system (workspace) starts getting refreshed. As far as I could tell that's the only feedback available.
In case any one else runs into issues with the configuration, I thought I would post some more details about the configuration ...
1. Server Path - provide the path to the srcsafe.ini file. This is usually the same network path mapping that you would do on your VSS client. Example - \\serverName\path\srcsafe.ini
2. VSS Folder Path - provide the path from the VSS Project Root. Example - $/ProjectRoot
3. Keep files as writable - I would recommend keeping this checked especially for .Net projects. In my case, I was using an Nant solution task to build a .Net project, relying on the same .sln & .csproj file used by developers (& checked in to VSS). The developers had custom PostBuildEvents configured in the .csproj files that were conflicting with the automated build ... by keeping the files as writable, I was able to xmlpoke and manipulate the PostBuildEvents.
4. Use Update - KEEP THIS UNCHECKED ALWAYS. When running .Net builds with this option checked, I found that compile errors would go unreported sometimes ... this was because some dependencies would be omitted by the compiler in the compile step as their assemblies (dlls) were already available. Keeping this unchecked slows down the build (get from VSS), but it is worth it.
Other issues -
I could not figure out how to setup the VSS Plugin on a Windows 2003 server that had Hudson configured as a service. The problem is that when Windows starts Tomcat as a service (I am running Hudson under Tomcat), the service is started by 'System'. There is no Network mapping available to the VSS share. The 'get' from VSS fails in this case.
I tried to start the service using a logon id, but even that didn't work.
I finally gave up and I am working around by having a logon startup .bat script to map the network drive to VSS + start Tomcat / Hudson. And I keep the logon session active always. It sucks, but that is the only setup I could get it working.