$/path/to/file.src does not exist in the repository

[slmcmahon]

I have written a web service and an application that will allow our fortress/vault users to deploy web content from a source repository directly to our TEST server. The web service maintains a login to the server in a singleton in order to avoid the login delay each time a file is deployed. The application will list the most recent revision of a file that is associated with a change ticket and allow the user to select one or many to push to the server. The problem that we are having is that occasionally the users will select a file to deploy and GetOperations.ProcessCommandGetVersion will return "XXX does not exist in the repository" where XXX is the Vault path to the file. I have confirmed on every occasion that the specific version of the file that I'm trying to retrieve does exist. Has anyone else had a similar problem that can offer me any suggestions?

[shannon]

Is that the exact error you're getting?

What version are you using?

[slmcmahon]

Is that the exact error you're getting?

What version are you using?

the exact error is:

"$/Database/FTL/Scripts/tblObjects_000_FTL_Fortress_065_FTL_32800.sql does not exist in the repository."

The method that is throwing the error is GetOperations.ProcessCommandGetVersion(fullpath, version, getoptions) in VaultClientIntegrationLib.dll verson 1.1.2.18185

[shannon]

Are you making a call to ServerOperations.SetWorkingFolder somewhere?

[slmcmahon]

Are you making a call to ServerOperations.SetWorkingFolder somewhere?

Yes. Just before that call. Here's the method that extracts the file from Fortress:

Code: Select all

private void GetFortressFile(ChangeSetItem csi, string diskPath) {
    ServerOperations.SetWorkingFolder(csi.FullPath, diskPath, true);
    GetOperations.ProcessCommandGetVersion(csi.FullPath, csi.Version, _getOptions);
    csi.DeploymentMessage = String.Format("Deployed version {2} of {0} to {1}.", csi.FullPath, diskPath, csi.Version);
}

ChangeSetItem is a dto class that I have that contains all of the information about the file that we want to deploy.

in the constructor of the containing class, I set _getOptions like this:

Code: Select all

_getOptions = new GetOptions
                  {
                      SetFileTime = SetFileTimeType.CheckIn,
                      Recursive = false,
                      MakeWritable = MakeWritableType.MakeAllFilesReadOnly
                  };

[shannon]

The error is coming from SetWorkingFolder. It looks like you're setting the working folder on the file and that isn't going to work. Set the working folder for the parent folder of the file.

[slmcmahon]

The error is coming from SetWorkingFolder. It looks like you're setting the working folder on the file and that isn't going to work. Set the working folder for the parent folder of the file.

I'll take a look at it from that perspective and see what I can find. I had just assumed that the error was coming from ProcessCommandGetVersion. It is worth nothing though, that the error only happens occasionally and after a while, when they try again, it will work. In the code that I showed you, diskPath is never a path to a file -- only to a directory, usually something like f:\webs\asite\afolder while csi.FullPath is usually something like $/webs/asite/apath/afile.cfm. I'll double-check everything to make absolute sure that diskPath is always set to a value.

Thanks for the help. I'll report back my results here once I have had success or failure.

Stephen

[slmcmahon]

This is a pretty old post, but I'm pretty sure that I have finally figured out what the problem is with this. I did go back and make sure that the working path was actually a folder name and not a file name, but the behavior never changed. The fact that this is only a temporary problem made it more difficult to figure out. Here's when I see it:

1. Add a new file to Vault/Fortress
2. Check it out, make a change and check it back in and associate it with a ticket.
3. Open up the tool that I have written to extract the source from Vault and put it on the destination server.
4. Click the "Deploy" button and get this error: "$/Path/to/file.ext does not exist in the repository."

Since i knew for a fact that I was passing in a valid value for the destination folder and the repository path was a value that I had actually retrieved programmaticaly from the repository, then I took a look at what SetWorkingFolder is actually doing and saw this:

Code: Select all

   VaultClientTreeObject parent = client.ClientInstance.TreeCache.Repository.Root.FindTreeObjectRecursive(s);
    if (parent == null)
    {
        throw new Exception(string.Format("{0} does not exist in the repository", s));
    }

The reference to "TreeCache" leads me to believe that the problem is that the client part of this application just hasn't been synced with the server yet when we get this error. It makes a lot of sense since it always works if we wait a while and try again. It looks like this bit of code should fix the problem if I call it first:

Code: Select all

ServerOperations.client.ClientInstance.TreeCache.DoLocalRefresh();

Does that sound right to you?

The error is coming from SetWorkingFolder. It looks like you're setting the working folder on the file and that isn't going to work. Set the working folder for the parent folder of the file.

I'll take a look at it from that perspective and see what I can find. I had just assumed that the error was coming from ProcessCommandGetVersion. It is worth nothing though, that the error only happens occasionally and after a while, when they try again, it will work. In the code that I showed you, diskPath is never a path to a file -- only to a directory, usually something like f:\webs\asite\afolder while csi.FullPath is usually something like $/webs/asite/apath/afile.cfm. I'll double-check everything to make absolute sure that diskPath is always set to a value.

Thanks for the help. I'll report back my results here once I have had success or failure.

Stephen

[shannon]

That sounds like it could fit. Try ClientInstance.Refresh() instead of DoLocalRefresh though.

[slmcmahon]

Thanks for the typical speedy reply. I will give this a shot and see if does the trick!

Stephen