Inherited working folder fails

[MH]

In working with the API (version 2.0.1), I came across a problem setting the working folder. For example, if I make this call:

myClient.TreeCache.SetWorkingFolder("$/myApps/foo", "C:\\myWorkingFolder");

the vault folder foo is correctly set to the working folder, but some of the subdirectories of foo aren't getting set to C:\myWorkingFolder\<subdirectory>. The funny thing is, some subdirectories in foo are correctly inherited.

So I headed over to the GUI; I read that "Working folders are automatically inherited in subfolders if no explicit working folder association exists for the subfolder." So I made sure that I unset foo, as well as all subdirectories in foo (oddly, the default appears to be My Documents, even after clearing the working directory, My Documents appears in the working directory). Anyway, after clearing all associations, I right-click on foo in vault and set the working directory to be C:\myWorkingFolder. Then, if I right-click all subdirectories in foo, I should see that $/myApps/foo/<subdirectory> is mapped to C:\myWorkingFolder\<subdirectory>. This is the case for SOME of the subdirectories, but there are still a few subdirecties under foo that refuse to inherit the working path. They are still reported as My Documents.

Is there a setting in the GUI I'm missing? If so, what is the call in the API to make sure this setting is cleared so all mapping works as expected?

Note: If I manually set the working directory of the "problem" subdirectories, it works - but this should happen automatically, right?

Thanks,
Mark

[jeremy_sg]

In order to reset the working folders from the API, you can use

SetWorkingFolder("$/path/subdir", null)

As for the problem unsetting the working directories from the GUI client, on most operating systems, the (admittedly non-intuitive) way to unset the working folder association is to bring up the Set Working Folder dialog, blank out the text in the text box, and then hit OK. Is this not working for you?

We plan to improve the Set Working Folder dialog quite a bit in the near future.

Another option is to use the command line client's UNSETWORKINGFOLDER command.

[MH]

Thanks for the speedy reply and for including the API call to unset a working folder.

As far as the GUI is concerned (using XP pro by the way).... I am clearing the working folder as you instructed. I right-click on the folder in vault, select the working folder menu option, then highlight and delete the contents of the textbox. If I repeat this set step immediately after I clear the textbox, I see that "My Documents" is put back in the previously cleared textbox.

Like I said before, it almost looks like a default setting, since "My Documents" keeps returning in all cases.

I tried some additional things too. After clearing all the working folders (even though "My Documents" is actually what's set), I ran the API call in VS.NET. Then, I returned to Vault's GUI. Just like before, it set the API specified directory "$/myApps/foo" to "C:\\myWorkingFolder";, but two of the eight subdirectories ($/myApps/foo/<subdirectories>) remained set to "My Documents" in the working folder setting. The other six were correctly set to C:\myWorkingFolder\<subdirectories>.

I can't see why these two subdirectories will not update their working folders. I've tried in both the API call and through the GUI. Like I said before, they can be set manually, but not automatically.

Any other insight?

Thanks,
Mark

[jeremy_sg]

"My Documents" is indeed the default selection in the Set Working Folder dialog when no working folder is set. The way to tell what the working folder is set to and if it is being inherited is the two labels above the file list view. The left one gives the folder path in the repository. The right one gives the working folder and if it is inherited or not.

In the API, after you set the working folder, you should do a ClientInstance.Refresh(). I found odd things would happen if I didn't. Check out http://weblogs.asp.net/Jeremy_Sheeley for an API example that sets a working folder, does some checkouts/modifications and checks in.

I hope that as we fix the Set Working Folder process, we'll have a checkbox that will clear the working folder associations for any subdirectories.

[MH]

Thanks for the example code. I played around with the GUI a bit more this morning; odd as it may seem, the inheritance is working better.

I'll head back to my API calls and see if I can emulate this behavior. If I don't see better results, I may just have to step through the subdirectories and verify that everything is pointing to the correct working folder.

Thanks much, I'll get back to you if I come across anything else.

Mark

[MH]

The API calls are working correctly (so far). I'm guessing the addition of myClient.Refresh() is the solution.

I have no idea why the "set working folder" in the GUI wasn't working yesterday, as it's working fine today.

Thanks,
Mark