rename and edit a file followed by get latest doesn't...

cpdaniel · Post by **cpdaniel** » Wed Feb 02, 2005 10:51 pm

Vault 2.0.6

If I rename a file, commit that change, edit that same file, commit that change, then go to another workstation to retreive those changes, two invocations of get latest on the parent folder are required to make the vault client show the file as up to date.

Is this fixed in 3.0.x?

bfinney · Post by **bfinney** » Thu Feb 03, 2005 11:29 am

I have reproduced this (though I can get it to happen without the subsequent edit) after a few tries and logged it, but it's not likely to be addressed soon.

It looks like this only happens when the get is performed on the file, not its parent, and only if the file list for that folder has not be refreshed. When the "get" command is issued, the client asks for that file... which no longer exists in the database. This first attempt does trigger a file list refresh, so the second attempt works.

This would actaully be a fairly substantial overhaul to how the client works, and would cause something of a slowdown. Hitting F5 prior to the get is probably the best workaround at this point - that will refresh the file list and cause the file to show up with the new name.

gmagana · Post by **gmagana** » Thu Feb 03, 2005 3:25 pm

Ok, I'll ask the stupid question: Couldn't the functionality of get latest simply be changed to "hit the F5 key" prior to continuing?

Under what circumstances would this be detrimental or harmful?

cpdaniel · Post by **cpdaniel** » Thu Feb 03, 2005 4:05 pm

bfinney - that doesn't match what I'm seeing here. For example, today I opened the Vault client on a machine that hasn't run vault since before I renamed/edited a few files. Get Latest from an ancestor (great-grandparent, at least) fetched the files, but their status shows as Unknown. Get Latest again results in messages saying that Unknown file xxxxx was overwritten, and then the file is gotten again. I didn't do any operations on the files themselves - only on the ancestor.

bfinney · Post by **bfinney** » Fri Feb 04, 2005 2:28 pm

gmagana wrote:Ok, I'll ask the stupid question: Couldn't the functionality of get latest simply be changed to "hit the F5 key" prior to continuing?

Under what circumstances would this be detrimental or harmful?

Not a stupid question at all. The get actually does refresh the file list... but it's after requesting the latest version of the file, so it's essentially a timing issue.

The olny time if could be bad (and it's not really that bad at all), is in cases where a lot of changes have been made to the folder, which would take a few seconds.

Thinking about it more carefully, the change woudn't be that big of a deal at all... and is thus more likely.

bfinney · Post by **bfinney** » Fri Feb 04, 2005 2:43 pm

cpdaniel wrote:bfinney - that doesn't match what I'm seeing here. For example, today I opened the Vault client on a machine that hasn't run vault since before I renamed/edited a few files. Get Latest from an ancestor (great-grandparent, at least) fetched the files, but their status shows as Unknown. Get Latest again results in messages saying that Unknown file xxxxx was overwritten, and then the file is gotten again. I didn't do any operations on the files themselves - only on the ancestor.

OK - the "unknown" aspect of this is important, and means that it's definitely fixed in 3.0. When I tried from an ancestor, my results pretty much match what you're seeing with 2.0.6. However, when moving into the folder that conatins the renamed file, it briefely flashes "unknonwn" before resolving to blank (up to date). Starting with 3.0, unknown statuses are resolved without user intervention.