GetWorkingFolderAssignments returns no folders

[smartbear]

We're getting no results from a ServerOperations.GetWorkingFolderAssignments() call. The vault command line, however, does return the working folders. Can you help?

I've attached the trace log from the Vault API, as well as our log (you can see in it when we enabled logging and when we call GetWorkingFolderAssignments).

Thanks,
Eric

[lbauer]

What version of Vault are you using? Is this a new problem -- did it work before or in a previous version?

[smartbear]

This has worked in all previous versions that we know of. I've never run into it, and I can't reproduce it on Vault v5.1.1 (19215). The problem has only been reported by the one customer, and apparently all their users see this problem. They are running with Vault Pro v5.1.1 (19216). The only slightly different aspect of their installation is that their regional settings are fr-CA.

[smartbear]

BTW, their "vault ... listworkingfolders" output returns:

Reposfolder="$" localfolder="C:\"

[lbauer]

Are you saying that Vault Command Line Client lists

$" localfolder="C:\"

when you run the listworkingfolders command?

What is the working folder for the user the Command Line Client and/or the API is running as?

The ccollab log reports this:

2011-05-20 15:46:16 com.smartbear.scm.impl.vault.VaultCommands getNormalizedWorkingFolderPath
FIN: C:\Micrium\Software\uC-FS\Source is not in a working folder

Where is it getting the info about this path?

[smartbear]

Linda,

Yes, when the customer runs the vault CLI it reports the one working folder $ mapped to C:\.

In our getNormalizedWorkingFolderPath method, we enumerate the working folders in order to match to a path. We loop through the working folders returned by GetWorkingFolderAssignments to find a matching working folder. We log each working folder found - these lines would appear in the log after the line:

FIN: GetWorkingFolderAssignments to match c:\micrium\software\uc-fs\source

but none are listed.

I would not have expected a discrepancy between the vault CLI and our use of the Vault API. It makes me wonder if something is happening with Mono. Do you have any clues from the Vault API log?

[lbauer]

Can we get the a copy of the command you are using within the command-line that returns a working folder, plus the API call you're using? Be sure to remove any passwords or other identifying info.

[smartbear]

Linda,

They run:

vault -host fortress.micrium.com:446 -repository Micrium -ssl -user francois01 -password XXXX listworkingfolders

and get:

<vault>
<listworkingfolders>
<workingfolder reposfolder="$" localfolder="C:\" />
<workingfolder reposfolder="$/Micrium/Software/uC-FS" localfolder="C:\Micrium\Software\uC-FS" />
</listworkingfolders>
<result>
<success>True</success>
</result>
</vault>

I added some code to our CLI "info" command that demonstrates what we're seeing:

StringBuilder sbFolders = new StringBuilder();
try {
SortedList workingFolders = ServerOperations.GetWorkingFolderAssignments();
IEnumerator iter = workingFolders.GetEnumerator();
while (iter.MoveNext()) {
DictionaryEntry entry = (DictionaryEntry)iter.get_Current();
sbFolders.append("\n").append((String)entry.get_Key()).append(" -> ").append((String)entry.get_Value());
}
if (sbFolders.length() > 0)
configInfo += "\nGetWorkingFolderAssignments:" + sbFolders;
else
configInfo += "\nNo working folders returned by GetWorkingFolderAssigments";
}
catch (NullPointerException e) {
configInfo += "\nException getting working folders: " + e;
ScmUtils.getLog().error(e);
}
return configInfo;

That produces this output (see last line):

Connecting to CodeCollaborator Server http://internet.micrium.com:9090/
Connected as: Francois Breton-Jacques (francois01)
SCM system is configured to 'vault'
SCM Type: Vault..
SCM Username: francois01
SCM Config: Micrium - fortress.micrium.com
No working folders returned by GetWorkingFolderAssigments

I can't reproduce this - I see the expected working folders listed. No other customers have reported this behavior either.

Eric

[lbauer]

So they connect with their client to their server, and it doesn't work.

You connect with your client to their server and it works?

Is there a way to rule out OS, or OS language pack, or any other variables?

[smartbear]

Sorry for the confusion. Both sets of output were generated on the same system. They connect to their server with vault.exe and it correctly reports the working folders. They connect to their server with our client (which uses your Java API) and no working folder mappings are returned.

[lbauer]

Since the Java API is cross-platform, it keeps track of the cache location in a different way than the Vault Command Line Client. There's a folder called Client with a "settings.xml" file in the cache location in the user's local profile. If you set working folders in the Vault GUI Client or with the Vault Command Line Client, the Java CLC or API won't know about them.

Try setting the working folder with the Java CLC or Java API and then see if your tool works.

[smartbear]

Linda,

So you're saying your Java API does not know the location of working folders as set by your Vault GUI Client?

It's certainly the case that we don't set working folders using the API and have so far relied on the working folders returned by ServerOperations.GetWorkingFolderAssignments. It is just this one customer case that does not appear to work.

Can you tell me what would be the expected steps in order to use your API to find local checkouts? Is it an entirely independent client instance from the Vault GUI client? Does the user have to go through and define the same working folders as used by the GUI client?

Thanks,
Eric

[jclausius]

Eric,

A user's working folders is stored inside a cache located in the user's local app data directory. The .NET based apps - Vault GUI, Enhanced, Classic and Command line, and .NET API based clients all rely on this location from the registry in a HKCU "CacheLocation" based string.

In regards to the Eclipse, Java CLC and Java API based clients, the cache location is controlled by a settings.xml file (found in the user's local app data directory structure).

One thing we've noticed is on different versions of Windows (XP vs. Vista vs. Win 7), the Java based clients will sometime use a different directory for the cache location, thus causing different clients to see different things. In this case, making sure the CacheLocation entry for settings.xml (using "forward slashes" instead of back slashes) matches the directory used by the .NET based clients ensures both clients are using the same client side cache data members.

HTH

[lbauer]

smartbear:

Was Jeff's information helpful? Do you need further assistance?

[smartbear]

Linda,

Yes - thank you! I updated the customer's settings.xml file to match the CacheLocation in the registry, and it fixed the problem. I'm still waiting for confirmation that this solves the problem for all their users.

I first considered ignoring the working folders altogether, hoping that a user selection or configuration of a given local path would do, but that doesn't give me the server path mapping. So rather than require that the user reproduce their working folder mapping(s) for our integration, it will just be a requirement that they update their settings.xml (if this occurs). Fortunately I've only heard of this issue from the one customer. If it becomes more common, I'll might supply a utility program to do the fixup.

Eric