I'm using cruise control .net for integration and am having some sort of wierd issue. When CC.net runs and gets the latest files all the files turn up flagged as renegade for the build user. Nothing is actually changed in the files and when I look at diffs they are the same. Some files actually end up with "Needs Merge" status; when I look at the merge I get the same on each side (repository and local) but the merge result has something different in it!
Here is the source control section:
<sourcecontrol type="vault">
<executable>C:\Program Files\SourceGear\Vault Client\vault.exe</executable>
<username>Build</username>
<password>Build's Password</password>
<host>esidev</host>
<repository>Default Repository</repository>
<folder>$/PIPE-FLO/current</folder>
<ssl>false</ssl>
<useWorkingDirectory>false</useWorkingDirectory>
<workingDirectory>c:\build</workingDirectory>
<autoGetSource>true</autoGetSource>
</sourcecontrol>
All files running renegade
Moderator: SourceGear
What version of Vault are you using?
Had you read our article on integration: http://support.sourcegear.com/viewtopic.php?p=2860
Some older versions of Vault had client-side cache file contention experienced by some CruiseControl.NET users. Some updates to that were made in Vault 3.1.8
Had you read our article on integration: http://support.sourcegear.com/viewtopic.php?p=2860
Some older versions of Vault had client-side cache file contention experienced by some CruiseControl.NET users. Some updates to that were made in Vault 3.1.8
No, I will now though.Beth wrote:What version of Vault are you using?
Had you read our article on integration: http://support.sourcegear.com/viewtopic.php?p=2860
[10/2/2006 3:46:16 PM] Version Check: This Vault client is version 3.1.9.3798Some older versions of Vault had client-side cache file contention experienced by some CruiseControl.NET users. Some updates to that were made in Vault 3.1.8
[10/2/2006 3:46:16 PM] Version Check: Your Vault server is version 3.1.9.3798
My version of CC.net is much later than what is being talked about in that zip. I think that must have been previous to the vault abilities being integrated in cc.net. My version is 1.1.0.2433; the zip file says to use .5 or .6-rc1.Beth wrote:What version of Vault are you using?
Had you read our article on integration: http://support.sourcegear.com/viewtopic.php?p=2860
In CC.NET 1.1, "UseWorkingDirectory" determines whether Vault does the get into a working folder, meaning it tracks file states (further described in the docs here).
Based on the fact that you're seeing any status at all, you must have a working folder set for the CC.NET Vault user in the location where you're getting the source for your build. Is there a reason for that? There's basically two schools of thought here:
1. Don't use a working folder and use cleanCopy, so you're retrieving all the source into an empty folder for every build. This is what we do.
2. Use a working folder, and don't use cleanCopy. So you're retrieving only the source that changed, and you have the option of committing changes made by your build script. This is really only a good idea if a full get of the source takes too long, or if you have to check in changes automatically at some phase of the build.
It looks like you've got kind of a mixture of the two. You have a working folder set, and you care about file statuses, but you have useWorkingDirectory set to false.
This is going to seem like a dumb question, but nonetheless: why do you care that the files are in Renegade status? If it doesn't really matter, you ought to go with option 1 above. If you care because you can't commit changes during the build, go with option 2.
Based on the fact that you're seeing any status at all, you must have a working folder set for the CC.NET Vault user in the location where you're getting the source for your build. Is there a reason for that? There's basically two schools of thought here:
1. Don't use a working folder and use cleanCopy, so you're retrieving all the source into an empty folder for every build. This is what we do.
2. Use a working folder, and don't use cleanCopy. So you're retrieving only the source that changed, and you have the option of committing changes made by your build script. This is really only a good idea if a full get of the source takes too long, or if you have to check in changes automatically at some phase of the build.
It looks like you've got kind of a mixture of the two. You have a working folder set, and you care about file statuses, but you have useWorkingDirectory set to false.
This is going to seem like a dumb question, but nonetheless: why do you care that the files are in Renegade status? If it doesn't really matter, you ought to go with option 1 above. If you care because you can't commit changes during the build, go with option 2.
Ian Olsen
SourceGear
SourceGear