CrouseControl 1.3 and Vault Client 4.1.2 cannot get source

[avonwyss]

I did read the other thread, but our issue seems to be different. In fact, everything seems to work just fine as it used to work with the old plugin. However, as soon as a build is triggered (wither by force or change detection), Vault throws an exception when or after getting the source files.

The Server log says:

Code: Select all

2008-06-04 13:58:21,320 [Assemblies:INFO] Project: 'Assemblies' is first in queue: 'Assemblies' and shall start integration.
2008-06-04 13:58:21,320 [Assemblies:DEBUG] In FortressVaultSourceControl.GetModifications()
2008-06-04 13:58:21,399 [Assemblies:DEBUG] Refresh() successful.
2008-06-04 13:58:21,399 [Assemblies:DEBUG] Current folder version is 236.  Last integrated folder version was 236.
2008-06-04 13:58:21,399 [Assemblies:INFO] [$/Assemblies/] has not changed.
2008-06-04 13:58:21,399 [Assemblies:INFO] No modifications detected.
2008-06-04 13:58:21,399 [Assemblies:INFO] Building: vonwyssa triggered a build (ForceBuild)
2008-06-04 13:58:21,399 [Assemblies:DEBUG] In FortressVaultSourceControl.GetSource()
2008-06-04 13:58:21,399 [Assemblies:DEBUG] Cleaning out source folder: C:\somepath\Assemblies
2008-06-04 13:58:22,383 [Assemblies:INFO] Getting source from Vault
2008-06-04 13:59:07,363 [Assemblies:INFO] Integration complete: Exception - 04.06.2008 13:59:07

And the build log:

Code: Select all

<cruisecontrol project="Assemblies">
  <request source="vonwyssa" buildCondition="ForceBuild">vonwyssa triggered a build (ForceBuild)</request>
  <modifications />
  <build date="2008-06-04 13:58:21" buildtime="00:00:46" buildcondition="ForceBuild" />
  <exception><![CDATA[VaultClientOperationsLib.GetLatestVersionFailedException: Exception of type 'VaultClientOperationsLib.GetLatestVersionFailedException' was thrown.
   at VaultClientOperationsLib.ClientInstance.ProcessGetFileRequests(GetFileInfo[] infos, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, Boolean updateHiddenFilesOnly, String ancestorFullPath, Boolean flat, String ancestorDiskPath, OverwritePrompt PromptData, Boolean isLabelGet, String currentPathToLabelItem, Int64 labelID, Boolean isRetry, Boolean isGetByDisplayVersion)
   at VaultClientOperationsLib.ClientInstance.Get(VaultClientFolder[] folders, Boolean forceLatest, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, OverwritePrompt PromptData)
   at VaultClientOperationsLib.ClientInstance.Get(VaultClientFolder folder, Boolean recursive, Boolean forceLatest, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, OverwritePrompt PromptData)
   at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressClient.GetVersion(String repositoryFolderPath, String workingDir, Int64 folderVersion)
   at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FortressVaultSourceControl.GetSource(IIntegrationResult result)
   at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build(IIntegrationResult result)]]></exception>
</cruisecontrol>

The project here has the following settings in the CCNET config:

Code: Select all

<workingDirectory>\somepath\Assemblies</workingDirectory>
		<artifactDirectory>\somepath\Assemblies</artifactDirectory>
		<modificationDelaySeconds>0</modificationDelaySeconds>
		<sourcecontrol type="vaultplugin">
			<username>someuser</username>
			<password>somepass</password>
			<host>vaulthost</host>
			<ssl>true</ssl>
			<repository>somrepository</repository>
			<folder>$/Assemblies/</folder>
			<autoGetSource>true</autoGetSource>
			<cleanCopy>true</cleanCopy>
			<useWorkingDirectory>true</useWorkingDirectory>
		</sourcecontrol>

It does not matter whether the console or service runs. The windows user used for both is administrator on the local machine, and using the Vault GUI Client (4.1.2, logged in as the same user CCNET runs in) it is possible to get the latest version of that path correctly. Working forders are set and valid. Interesting thing is that not only the folder version checks do work fine, but the working directory gets cleaned out and refilled when one looks at the directory while CCNET integrates this project, which would suggest that the operation does (mostly?) succeed.

All our integrated projects (some 30 or so) show exactly the same behavior, this is not just one exceptional project. I did delete the temporary folder of the client and re-set the working folder, but this did not change anything. Therefore I start wondering whether that "autoGetSource" option is working at all?

[shannon]

Have you tried restarting the machine?

[avonwyss]

Have you tried restarting the machine?

Yes. Does not change anything.

[shannon]

I have seen this error a couple times, but have not been able to reproduce it. It may be failing to get just one file or folder. I am looking into it.

[shannon]

If you switch back to the old plugin, does this error go away?

[gsmalter]

I had this error too and figured it out. It sucks.

Here's the deal. It has to do with the working folder. Sometimes, setting the working folder explicitly on the problem project (NOT inheriting from $) would fix the issue. Other times, not.

The ultimate fix was to use the following elements in the <sourceControl> element of Cruise Control to override the working folder (double check the names of these elements).

// This really means "don't use the working folder Vault says to use"
<useWorkingFolder>false</useWorkingFolder>
// This specifies the working folder, which really is the same as the one
// Vault is defaulting to, but the difference is that this actually works.
<workingFolder>C:\MyVaultWorkingFolder\MyProject\xxx</workingFolder>

This problem just now arose, after years of using CCNET and Vault together. Anyway, this is our fix. Good luck.

[avonwyss]

If you switch back to the old plugin, does this error go away?

Yes, the old plugin works like a charm, but with our amount of projects it's very resource-consuming.

gsmalter, thank you very much for the suggestions! I'll try them out. Nevertheless, I'm convinced that this is some bug in the new plugin.

[ian_sg]

// This really means "don't use the working folder Vault says to use"
<useWorkingFolder>false</useWorkingFolder>
// This specifies the working folder, which really is the same as the one
// Vault is defaulting to, but the difference is that this actually works.
<workingFolder>C:\MyVaultWorkingFolder\MyProject\xxx</workingFolder>

It's my fault that this is so confusing. The meaning of "useWorkingDirectory" doesn't match people's expectations at all. But it is documented.

The useWorkingDirectory setting, when true, means that source is retrieved into a full-fledged working copy. This is useful if you change source and check the changes as part of your build. It's also useful if you want the get latest to retrieve strictly what's changed.

It does not mean to use an existing working folder assignment to determine where on disk to stick the source. Which is unfortunately what people intuitively expect it to mean.

Note that this is how the old plugin works, too.

[gsmalter]

All I know is that it ignored the path I specified in <workingDirectory> until I supplied false for <useWorkingDirectory>.

[avonwyss]

It does not mean to use an existing working folder assignment to determine where on disk to stick the source. Which is unfortunately what people intuitively expect it to mean.

Note that this is how the old plugin works, too.

Ian, how does this have anything to do with the issue reported? I don't see the relation, since I'm getting an Exception even though it does seem to be doing something...

Also, in the documentation you have linked to, the "useWorkingFolder" is described as follows:

Vault Working Folder Defined

Most version control systems have distinct commands for "get me the source" and "get me the source into a folder where I may make changes." Vault is no exception. A working folder is a folder where Vault will keep track of your changes. If you're using CC.NET 1.1.0.2172+, the useWorkingFolder setting determines whether Vault retrieves source into a working folder. For build purposes, there are typically two situations where you want to retrieve source into a working folder:

1. Your build script changes source and checks in the change
2. It's taking longer than you'd like to retrieve the source

Because of the additional state information kept by Vault for working folders, retrieving source into a working folder is usually faster than into a non-working folder. The trade-off is that more disk space will be used for cache and state data.

So, when I have working folder locations set up properly and use this feature, I expect the plugin to use the working folder that was set up in the client and to ignore the workingFolder setting (which it seems to be doing).

[ian_sg]

I was responding primarily to gsmalter. Your expectations are correct.

Based on what gsmalter has said, I've logged a bug to verify that the new plugin is still using the behavior I described. It certainly does sound, based on your information, that there's a bug in the new plugin.

If you force a path via the "workingFolder" setting, as gsmalter suggested, does anything change?

[gsmalter]

Sorry, I didn't mean to sidetrack this thread, I was just trying to share my solution, but I just want to clear a few things up.

First, it is not my belief that the new plugin is broken, in that the behavior of useWorkingDirectory and workingDirectory seemed consistent to me between the two versions. Also, I experienced the original poster's problem with BOTH plugins, not just the new one. But, the problem was semi-random, so that could explain why the OP only experienced the problem with the new plugin.

The new plugin could, however, use better error logging.

Second, my tests made me believe that the useWorkingDirectory element could be accurately named useVaultGUISpecifiedWorkingDirectory. I may be wrong, but it does seem to jive with the documentation you pointed to. I didn't really understand your description in this post, however (what would a non-full-fledged working copy be?).

Anyway, I hope the OP solves their problem, and I don't think the behavior of the new plugin needs to be changed (from my experience) other than improved error logging. There definitely is something with 4.1.2, though, that caused these Get Latest errors for both of us, and that should probably be addressed.

[samuel_d_jack]

I'm having the same problem.

I tried setting useWorkingDirectory to false, but that hasn't made a difference.

As an aside, does this new Plugin support the LastChangeLabeller, as requested in this post http://support.sourcegear.com/viewtopic ... gelabeller?

Hope you can help.