get source from ccnet

[bwhite]

Our CCNet project is getting the source from Vault and it gets all but two directories.
We are not treating those directories any differently when we check in. I just doesn't
retrieve them, and we can't see any reason for it.

This user does not have a working directory defined. It is specified on the command line.

Here is the command being run, from the log file:
2009-03-16 12:22:01,129 [Insite Web Service Generator:DEBUG] Starting process [C:\Program Files\SourceGear\Vault Client\vault.exe] in working directory [C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory] with arguments [getversion 39128 $/Beta7.0/ C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory -useworkingfolder -merge overwrite -makewritable -backup no -setfiletime checkin -host ibsech -user test -password ######## -repository Synergy]

This is only with the command line tool. The UI gets the directories normally.
This isn't much help since CCNet will delete all the dirs before getting the latest source.

One difference between the UI and CL, CL is getting a specific version, the latest, 39128 in the above example,
whereas the GUI is just getting the latest. That doesn't seem like a sufficient reason to fail, but is
the only difference I can think of.

Vault 4.0.4

Thanks,
Brad.

[lbauer]

If you just run this command with the Vault CLC (apart from CCNet) does it work? If not, are there any errors in the The Vault server log? The server log is sgvault.log and is in %windir%\temp\sgvault on the server machine.

[bwhite]

Linda,

Looks like the command line is going to go through. It has created all the dirs and
has started populating the exe dir.

"test" is the ccnet user.

Here is the relevant portion of the log:
----3/16/2009 1:25:26 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:38:02 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:38:02 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:38:24 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:41:24 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:44:10 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:44:12 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:44:15 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:44:16 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:44:19 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:44:22 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:44:23 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:44:43 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:45:19 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:47:13 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:48:35 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:54:21 PM Jwood--IBSECH.asiweb.com(10.2.0.44)--SSL Disabled Login
----3/16/2009 1:56:33 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:56:35 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 1:56:52 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 1:58:53 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Critical Error downloading file! The remote host closed the connection. The error code is 0x80072746.
at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async)
at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal)
at System.Web.Hosting.ISAPIWorkerRequest.FlushResponse(Boolean finalFlush)
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpResponse.Flush()
at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size)
at System.Web.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.BufferedStream.Write(Byte[] array, Int32 offset, Int32 count)
at VaultServiceSQL.VaultSqlSCC.GetDeltaChainForFullFile(VaultSqlConn conn, Int64 nObjVerID, Int32 nBufSize, String strFileToken, Stream s, ListDictionary ldDataStreams, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultFileCacheManager.GetDeltaChainForFullFile(VaultSqlConn vsConn, Int32 nRepID, Int64 nTargetObjVerID, Int32 nBufSize, String strFileToken, Stream sFullFileStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultDelta.CreateFullFile(VaultSqlConn vsConn, Int32 nRepID, Int64 nObjVerID, String strFileToken, Boolean& deltaIfAvailable, Stream sFullFileStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultDelta.DeltaCreate(VaultSqlConn vsConn, Int32 nRepID, Int64 nBaseObjVerID, Int64 nTargetObjVerID, String strFileToken, Stream sDeltaStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultServiceAPI.GetVaultFile(Int32 nRepID, VaultIntDnldItem& vidi, String strFileToken, Stream s, Boolean bSeekToOrigin, Boolean bFolderExportCalcCRC, UInt32& nCRC)
at VaultService.VaultFileDownload.Page_Load(Object sender, EventArgs e)
----3/16/2009 1:58:53 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled System.Web.HttpException: The remote host closed the connection. The error code is 0x80072746.
at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async)
at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal)
at System.Web.Hosting.ISAPIWorkerRequest.FlushResponse(Boolean finalFlush)
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpResponse.Flush()
at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size)
at System.Web.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.BufferedStream.Write(Byte[] array, Int32 offset, Int32 count)
at VaultServiceSQL.VaultSqlSCC.GetDeltaChainForFullFile(VaultSqlConn conn, Int64 nObjVerID, Int32 nBufSize, String strFileToken, Stream s, ListDictionary ldDataStreams, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultFileCacheManager.GetDeltaChainForFullFile(VaultSqlConn vsConn, Int32 nRepID, Int64 nTargetObjVerID, Int32 nBufSize, String strFileToken, Stream sFullFileStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultDelta.CreateFullFile(VaultSqlConn vsConn, Int32 nRepID, Int64 nObjVerID, String strFileToken, Boolean& deltaIfAvailable, Stream sFullFileStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultDelta.DeltaCreate(VaultSqlConn vsConn, Int32 nRepID, Int64 nBaseObjVerID, Int64 nTargetObjVerID, String strFileToken, Stream sDeltaStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultServiceAPI.GetVaultFile(Int32 nRepID, VaultIntDnldItem& vidi, String strFileToken, Stream s, Boolean bSeekToOrigin, Boolean bFolderExportCalcCRC, UInt32& nCRC)
at VaultService.VaultFileDownload.Page_Load(Object sender, EventArgs e) at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async)
at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal)
at System.Web.Hosting.ISAPIWorkerRequest.FlushResponse(Boolean finalFlush)
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpResponse.Flush()
at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size)
at System.Web.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.BufferedStream.Write(Byte[] array, Int32 offset, Int32 count)
at VaultServiceSQL.VaultSqlSCC.GetDeltaChainForFullFile(VaultSqlConn conn, Int64 nObjVerID, Int32 nBufSize, String strFileToken, Stream s, ListDictionary ldDataStreams, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultFileCacheManager.GetDeltaChainForFullFile(VaultSqlConn vsConn, Int32 nRepID, Int64 nTargetObjVerID, Int32 nBufSize, String strFileToken, Stream sFullFileStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultDelta.CreateFullFile(VaultSqlConn vsConn, Int32 nRepID, Int64 nObjVerID, String strFileToken, Boolean& deltaIfAvailable, Stream sFullFileStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultDelta.DeltaCreate(VaultSqlConn vsConn, Int32 nRepID, Int64 nBaseObjVerID, Int64 nTargetObjVerID, String strFileToken, Stream sDeltaStream, RunningCRC32 crc, UInt32& nCRC)
at VaultServiceAPILib.VaultServiceAPI.GetVaultFile(Int32 nRepID, VaultIntDnldItem& vidi, String strFileToken, Stream s, Boolean bSeekToOrigin, Boolean bFolderExportCalcCRC, UInt32& nCRC)
at VaultService.VaultFileDownload.Page_Load(Object sender, EventArgs e)
----3/16/2009 1:59:01 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 2:04:43 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 2:04:44 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout
----3/16/2009 2:05:03 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Login
----3/16/2009 2:08:21 PM test--devbuild.asiweb.com(10.2.0.86)--SSL Disabled Logout

[bwhite]

The error I posted from the log was stamped as 1:58 PM. No idea what was going on at 1:58 but that was the only error showing. The CCNet build project ran again last night and again failed to get those two dirs. No errors in the log at all.
Just 'test' connecting and disconnecting as it got different projects.

Again, I can 'get' from the UI and from the command line, just not from CCNet. Here is the command again:

2009-03-16 12:22:01,129 [Insite Web Service Generator:DEBUG] Starting process [C:\Program Files\SourceGear\Vault Client\vault.exe] in working directory [C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory] with arguments [getversion 39128 $/Beta7.0/ C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory -useworkingfolder -merge overwrite -makewritable -backup no -setfiletime checkin -host ibsech -user test -password ######## -repository Synergy]

This 'gets' 9 of the 11 dirs perfectly.
I included all these options in the CL run, including the 'getversion 39128', so I don't expect that is the problem.

Thanks,
Brad.

[jeremy_sg]

If you run the command line from the build machine, does it complete successfully?

Our interpretation of the "Critical Error downloading file!" message is that something killed the client process, or the client's connection in the middle of downloading a file. Do you see anything in your Vault client log files?

[bwhite]

Yes, the log file says that it is downloading those two dirs to different locations.
I can't see why it would do that.
I have logging set to all. I still can't see the exact command that Vault is getting
that would tell it to send some directories anywhere other than the specified working directory.

I see now that the dir it is going to is for another project.

Do you want me to send this log any where when this is finished?

We've started explicitly setting the working dirs for EXE and SRC and I can see in the Vault log that it
is ignoring that.

Here is the relevant text of our current CCNet project, followed by a portion of the log:
<exec program="${VAULT}\Vault.exe" workingdir="C:\CruiseControl\"
commandline="GET -host ibsech -username test -password 1q2w#E$R -repository Synergy -workingfolder C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory $/Beta7.0">
</exec>

<exec program="${VAULT}\Vault.exe" workingdir="C:\CruiseControl\"
commandline="GET -host ibsech -username test -password 1q2w#E$R -repository Synergy -workingfolder C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory\Src $/Beta7.0/Src">
</exec>

<exec program="${VAULT}\Vault.exe" workingdir="C:\CruiseControl\"
commandline="GET -host ibsech -username test -password 1q2w#E$R -repository Synergy -workingfolder C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory\Exe $/Beta7.0/Exe">
</exec>


You can see in the first 4 lines here that EXE is not going to the folder specified, but that of InsiteTesting.
3/17/2009 2:21:53 PM <wf>: [<No Name>:4692] wf C:\CruiseControl\InsiteTesting\WorkingDirectory\Source\Exe mutex locked
3/17/2009 2:21:53 PM <mutex>: [<No Name>:4692] Released mutex 904
3/17/2009 2:21:53 PM <wf>: [<No Name>:4692] wf C:\CruiseControl\InsiteTesting\WorkingDirectory\Source\Exe mutex released
3/17/2009 2:21:53 PM <wf>: [<No Name>:4692] wf for C:\CruiseControl\InsiteTesting\WorkingDirectory\Source\Exe created

In the next line, we see that all the rest of the repository does go to the correct location:
3/17/2009 2:21:53 PM <mutex>: [<No Name>:3144] Created mutex 908 (Vault_WF_-191277242)
3/17/2009 2:21:53 PM <mutex>: [<No Name>:3144] Took mutex 908
3/17/2009 2:21:53 PM <wf>: [<No Name>:3144] wf C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory mutex locked
3/17/2009 2:21:53 PM <mutex>: [<No Name>:3144] Released mutex 908
3/17/2009 2:21:53 PM <wf>: [<No Name>:3144] wf C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory mutex released



Thanks,
Brad.

[jeremy_sg]

What do you see if you run

vault.exe -server (etc) listworkingfolders

on the build machine?

[bwhite]

What do you see if you run

vault.exe -server (etc) listworkingfolders

on the build machine?

Um, couldn't make anything out of the -server parameter.

Running
vault.exe -host ibsech -username test -password ######## -repository Synergy listworkingfolders

gives
<vault>
<listworkingfolders>
<workingfolder reposfolder="$" localfolder="C:\InsiteTesting\src" />
</listworkingfolders>
<result>
<success>True</success>
</result>
</vault>

Which is about what I expected. This user doesn't have many working folders defined
as they are all specified on the command line. Interestingly, the two AWOL dirs
are both going under the working folder shown here, instead of the one specified
on the command line as the rest are doing.
We'll try removing this one fixed working folder and see if that has any effect.

This is a 4.0.4 server and we are planning to move to 4.1.4 in the next week or two.

Thanks,
Brad.

[bwhite]

> We'll try removing this one fixed working folder and see if that has any effect.
Not so much.

Removed the working dir. listworkingfolders now shows nothing:
vault.exe -host ibsech -username test -password 1q2w#E$R -repository Synergy listworkingfolders
<vault>
<listworkingfolders />
<result>
<success>True</success>
</result>
</vault>

Files are still going to the wrong location, for just those two dirs.

To add to the intrigue, we have another project with similar named dirs that this one is overwriting.
Just checked and the build file for the other project is getting the same repository folder as this
project, and setting (from the command line) the working folder, exactly the directory path that
our rouge is writing to.
That sounds promising, but raises two questions.
1) Why only those two and not the other three sub dirs that the two projects have in common?
2) How does it remember from one run to the next? We stop and restart CCNet and then force
the build on our project, and it still goes to the directory specified by the other project.
We can see from the listworkingfolders results that it is not staying set.

Here are just a couple of snippets from the log file.
3/18/2009 11:08:16 AM <wf>: [<No Name>:6052] wf C:\CruiseControl\InsiteTesting\WorkingDirectory\Source\Exe mutex
3/18/2009 11:06:53 AM <wf>: [<No Name>:6052] wf C:\CruiseControl\InsiteWebServiceGenerator\WorkingDirectory\Wsc
mutex
You can see that the EXE dir is clearly going to the sub dir of the old InsiteTesting project.
But the Wsc folder is going to the correct forlder for this project, off the same command line.

Thanks,
Brad.

[bwhite]

Changing the user name on the command line is sufficient to get rid of the residual working directory.

To sum up:
The same exact command, using the CLC, with the working directory specified on the CL,
using a different user, gave different results by GETting the files to different locations.
One user gives the correct results, as dictated by the CL, and the other overwrites a previous
GET, even though files in that dir have been updated (re-compiled) since the last GET
to that dir.

This solves it for us. We'll just use the other "user" for that project.

Unless you want to pursue this further, I think we are done.

Thanks for the help,
The listworkingfolders and the client log file are what broke the case open. We were just stumped until
we saw the results there.

Brad.

[lbauer]

Each Vault user has their own client-side cache, with information about working folders, etc. I'm wondering if you delete the cache for each user, whether you get the same results.

http://support.sourcegear.com/viewtopic.php?t=6

[bwhite]

Good point.

And I'm logging in as a different windows user when I'm doing my tests that get different results
than the login that the service uses. I was using the same vault user in both cases and expecting
the same results.

I'll test this with deleting the cache and see what we get.

Thanks,
Brad.

[bwhite]

Yup, it was the cache that was causing the problem.
Clearing the cache allowed both CCNet projects to download their code to the correct directories regardless of who goes first. We can cause problems if we run both at the same time. So, even though that would rarely happen, we will change one of the projects to use our guest account.

Thanks for the help on this,
Brad.

[lbauer]

Glad we were able to solve the mystery.