"Get Latest Version" randomly fails, but deletes f

link · Post by **link** » Tue Mar 14, 2006 4:39 am

We're having some major issues with the Get Latest Version option in Vault. We recently upgraded to the latest version (our version was over a year old) hoping these issues would be fixed, but they're still causing problems.

Basically, if I do a Get Latest Version and let it complete, then do it again, I see more files pulled out even though nobody has committed any changes. It took 5 times last week before it stopped pulling out changes. Here's a snip from the Messages tab this morning. Nobody committed anything to this folder between my Get Latest Version actions. You can see the second action pulls out more files.

[14/03/2006 09:45:01] Version Check: This Vault client is version 3.1.7.3719
[14/03/2006 09:45:01] Version Check: Your Vault server is version 3.1.7.3719
[14/03/2006 09:45:01] Version Check: The following information was retrieved from the SourceGear website. No information was sent to SourceGear. You can disable this part of the version check from the Options dialog.
[14/03/2006 09:45:01] Version Check: The most recent Vault release is version 3.1.8.3771
[14/03/2006 09:45:10] Getting latest version of $/Testing
[14/03/2006 09:48:15] Fetched $/Testing/Automated/Mercury Tests/Reusable Tests/Common/Parameters.mtr
[14/03/2006 09:48:15] Fetched $/Testing/Automated/Mercury Tests/Reusable Tests/Common/lock.lck
[14/03/2006 09:48:15] Fetched $/Testing/Automated/Mercury Tests/Reusable Tests/Common/default.cfg
[14/03/2006 09:48:15] Fetched $/Testing/Automated/Mercury Tests/Reusable Tests/Common/Test.tsp
[14/03/2006 09:48:15] Fetched $/Testing/Automated/Mercury Tests/Reusable Tests/Common/Action1/Script.mts
[14/03/2006 09:48:15] Fetched $/Testing/Automated/Mercury Tests/Reusable Tests/Common/Action1/Resource.mtr
** I've snipped lots more files **
[14/03/2006 09:48:22] Finished get latest of $/Testing
[14/03/2006 09:50:57] Getting latest version of $/Testing
[14/03/2006 09:51:14] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/Parameters.mtr
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/lock.lck
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/PrivilegeRoleModifyPrivilegeRemove.usr
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/Test.tsp
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/default.cfg
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/default.prm
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/thin_usr.dat
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/default.usp
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/thick_usr.dat
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/Default.xls
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/Action0/Script.mts
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/Action0/Resource.mtr
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/Action2/Script.mts
[14/03/2006 09:51:15] Fetched $/Testing/Automated/Mercury Tests/Platform/System Configuration/System Setup (Web)/Privilege Roles/PrivilegeRoleModifyPrivilegeRemove/Action2/Resource.mtr
[14/03/2006 09:51:15] Fetched $/Testing/Datasets/SalesDemo.lbk
[14/03/2006 09:51:15] Finished get latest of $/Testing

What's more worrying, is that the folder containing the files listed in the second list did exist on my disk before the first Get Latest Version. After the first one, the folder had gone from my disk, and the second one brought it back. This suggests the first action delete the files, and then didn't pull them out of the repository (yet reported no errors).

link · Post by **link** » Tue Mar 14, 2006 4:41 am

If it's any help, the last time these files were committed was by myself (so I know they existed on disk) yesterday at 15:46 - over 12 hours before my first Get Latest Version

dan · Post by **dan** » Tue Mar 14, 2006 9:01 am

The first place to start with something like this is the client log. If you can reproduce it easily, turn on client logging and repeat the steps and send us the log. Directions for turning on client logging are here: http://support.sourcegear.com/viewtopic.php?t=1534

link · Post by **link** » Thu Mar 16, 2006 3:36 am

I did this, and have an 9MB log file (I set classes to "all", because I wasn't sure which were important) from doing Get Latest Version twice. The second time it pulled out some files that hadn't been touched for 3 hours, that it'd missed the first time.

Do you have an email address I can send the log to, or should I attach it here?

dan · Post by **dan** » Thu Mar 16, 2006 9:27 am

Zip it up and send it to my email address (press the email button below).

I've spent quite a bit of time looking at this, and think I may have found a case where this happens. If your option to "perform repository deletions locally" is not set to "Do not remove working copy", and you've deleted a repository folder and then added a new folder of the same name, the next time you do a Get it will remove files in that folder that were not retrieved as part of the Get.

Sorry for the confusing description, but a simple work-around would be to set the "Peform Repository Deletions" to "Do not remove working copy".

However, it would be good to verify this is the problem you are seeing. Do you do a lot of repository folder deletions, and does a subsequent Get retrieve everything correctly from that folder? Or, is it possible that Visual Studio is deleting and recreating folders without you knowing about it?

link · Post by **link** » Thu Mar 16, 2006 10:08 am

The email button goes to a form, which doesn't have attachment options. Could you PM me your email address?

We do indeed often delete folders, because it seems the easiest way to add new subfolders (our testing software generates new folders in each test quite a lot!).

My option for deletions is "Remove working copy only if unmodified"

link · Post by **link** » Thu Mar 16, 2006 10:15 am

This is starting to make sense now. Since our local copies are unmodified, they're being removed (because the repository ones were). However, I would expect the new copy to be pulled out at the same time (unless it's happening before the deletion of the old one?)

One things that doesn't make sense, is that before now, I've hit Get Latest Version 4 times, and the first three (at least) pulled out files. Maybe this could be explained if the folder was deleted, added, deleted and added again? (eg. if the person adding wasn't sure it worked properly, and did it again?).

The workaround you gave will probably sort us for now, but it would be nice to have deletes work correctly, and new files then pulled out - would this be considered a bug, and fixed?

link · Post by **link** » Thu Mar 16, 2006 10:25 am

Incidentally, we're using the vault client, and not Visual Studio. We modify the files in Mercury QuickTest Pro

dan · Post by **dan** » Thu Mar 16, 2006 10:52 am

This is definitely a bug, and one that we will fix as soon as we can. Luckily, there is an easy workaround for it.

No need to send me the log file if changing the option addresses it, since that will confirm the what the issue is.

link · Post by **link** » Mon Mar 20, 2006 3:38 am

It looks like we may have a problem with this workaround...

When we do Get Latest Version, rather than delete the file as it did before, it leaves them on disk (the old, stale version), until we do another Get Latest Version. This means, whereas before we had files missing (which we knew was caused by this problem, and would just do another Get Latest Version), we now have stale files after Get Latest Version (if we don't do it twice), which could result in modifying stale files and overwriting work in the repository.

Is there any posibility of a patch/hotfix for this, or do we have to wait for a new Vault release? If so, any estimations on when this will be (weeks? months?)

Thanks

lbauer · Post by **lbauer** » Mon Mar 20, 2006 8:52 am

This bug is marked High priority for our next release, which is due out in a few months.

link · Post by **link** » Wed Mar 22, 2006 9:22 am

Given that this is such an important issue and the workaround could have us working on old versions of files is there any way to either get a more accurate estimate on a new release than "a few months" or maybe get this issue fixed as a hotfix or minor point release?

Thanks

lbauer · Post by **lbauer** » Wed Mar 22, 2006 11:15 am

We understand this is a problem for you and will try to get it fixed as soon as possible. I don't have a specific timeframe, because we don't yet know what would be involved in fixing the problem and testing the fix.

dan · Post by **dan** » Mon Mar 27, 2006 10:29 am

Hi Link,

We'll be looking more in-depthly at this problem this week, and can hopefully get at least a debug version out to you this week or next, depending on what we find.

I had understood that when you set Perform Repository Deletions to "Do not delete locally", the Get would properly retrieve all files with a status of Old, but it would not remove any files that had been deleted.

Are you seeing it not retreive files with status of Old?

One other note: If you edit a file with a status of Old, its status should become Needs Merge, and it should require you to merge the file before checking it in. However, no work should be lost in that case, because the Merge should include both sets of changes. Are you seeing this, or invoking "Resolve Merge Status" before doing the merge?

link · Post by **link** » Tue Mar 28, 2006 1:49 am

When we set it not to remove local copies, it still seemed to only get some files on the second attempt. After the first Get Latest Version, we seemed to still have old files, and only the second one then updated them.

Is there any more detailed logging I could enable and try to reproduce this to send you a log? Or does the normal logging (with classes set to "all") contain enough information to be helpful to you?