Issue with deleting local files on update

[richardf8]

We have integrated Vault into our application to maintain version control over the application's project files. Multiple users can edit the same project with Vault providing the required locking and control mechanisms. Since the upgrade to Vault 5 (client and server) we are having issues with the handling of local files following an update.

1) A user creates a project and adds (in this case some roads)
2) A second user checks out the project.
3) The first user deletes a road - this locks the road, deletes it and then commits the changed files. The first user's local files are removed correctly.
4) The second user tries to edit the deleted road, this results in a lock failure exception as the files are no longer in Vault. This implies the second user's project is out of date.
5) The second user performs a get latest to bring their local files up to date, the get latest always sets the RemoveWorkingCopy mode in the GetOptions.
6) The second users local files are NOT deleted as they should be.

This used to work just fine in Vault 4.

If the user does not attempt to lock the road files before doing the update the files are correctly removed.

It appears that attempting to lock the files prevents subsequent attempts to update from removing the local files.

Thoughts/suggestions?

Thanks
Richard Laing
Forum8 (NZ) Ltd.

[lbauer]

We'd like to try to reproduce this here.

What version of Vault are you using? What version of Visual Studio? Are you using the Enhanced or Classic Client for integration?

I'm not sure what you mean by "road." Is this a type of file/project?

[richardf8]

We are using the Vault Client API directly, currently 5.0.4.18845. We have build the client into the application, when the user wants to edit some part of the project we lock/add/delete the appropriate files in Vault.

The server version is 5.0.3.18802.

A road is part of our data model and consists of one or more files under Vault source control.

It looks like maybe something has changed with the status/lock handling in Vault 5. Before trying to lock we currently check the status of the file(s) so we can tall the user if another user has the file(s) locked. Since the file is deleted it has no status and we try and lock it, this fails (exception since the file does not exist in Vault). Subsequent updates fail to remove the working file. If we do not attempt to check the status and lock the file the update works just fine.

All this worked as expected in Vault 4. I am continuing to try and establish exactly what call causes the problem.

[richardf8]

I don't know if this helps but the code used when getting the latest from the repository is as follows:

public void GetLatest(string[] objectPaths)
{
GetOptions getOptions = new GetOptions();

getOptions.PerformDeletions = PerformDeletionsType.RemoveWorkingCopy;
getOptions.Recursive = true;
getOptions.Merge = MergeType.OverwriteWorkingCopy;

GetOperations.ProcessCommandGet(objectPaths, getOptions);
}

When performing the Checkout I have tried:

public void ProcessCommandCheckout(string[] objectPaths, bool checkoutExclusive, bool getLatest)
{
GetOptions getOptions = new GetOptions();

getOptions.PerformDeletions = PerformDeletionsType.RemoveWorkingCopy;
getOptions.Recursive = true;
getOptions.Merge = MergeType.OverwriteWorkingCopy;

ServerOperations.ProcessCommandCheckout(objectPaths, checkoutExclusive, getLatest, getOptions);
}

passing both true and false for the getLatest parameter, neither appears to work.

[lbauer]

Is the GET w/ Perform Local Deletions done on a file or folder?

We tested this scenario with both Vault 4 and 5. In both versions, the file was not removed from the working folder unless a Get Latest was done at the folder level.

[richardf8]

This is done on a folder level.

[lbauer]

Hmm. Could you run ProcessCommandGet() through a debugger, and see if you spot anything when ProcessCommandGet makes a call to PerformPendingLocalDeletions() ?

[richardf8]

When calling ServerOperations.ProcessCommandCheckout(objectPaths, checkoutExclusive, getLatest, getOptions); the value if getLatest is definitely set to false.

When attempting to lock the file I get an exception message 'No object was found at the repository path $/richard/Test8192/paths/blah.path'

After this exception GetLatest always fails to remove the file.

Still looking ...

[lbauer]

What if you run ProcessCommandGet() -- rather than checkout -- through a debugger? What happens when ProcessCommandGet makes a call to PerformPendingLocalDeletions() ?

[richardf8]

As long as I don't do the checkout (or request the status using ProcessCommandStatus) the get works correctly and the local files are removed.

[richardf8]

I thought I had a fix by checking if the file exists using the RepositoryUtil.PathExists() method. I pass in the full repository path to the file. Unfortunately this returns true for the deleted file - the file has been deleted and the change committed on another PC.

I really don't think it should be returning true in this case, the file has definitively been removed from the repository.

[richardf8]

Another update, I tried calling the RepositoryUtil.Refresh method before checking if the path exists. This is good, I now get the path reported as missing - the file does not exist. Great but a subsequent update does not remove the local file. What does the refresh do...

[richardf8]

I think I have finally tracked down what is happening. We were explicitly setting the working folder details before doing the GetLatest operation. If we don't do that the update correctly removes the files.

The working folder is set to the same values (it was not being changed in fact).
Setting the working folder only broke the update if a file had been deleted.
This used to work just fine in Vault4.