Recursive pull by label didn't get correct file version
Moderator: SourceGear
Recursive pull by label didn't get correct file version
I applied a label to a branch folder using Vault. I then went to my build machine and attempted to do a get by that same label recursively. Upon inspection, I noticed that a couple of the files were not overwritten. One was an .XSX file and one was a .cs file. Even upon inspection in Vault, the UI showed the files as being "old", when the newest version should have been pulled. When I selected the file itself and pulled by the label, it worked, but the recursive pull from two folders up failed to get the file. Are there any know issues regarding this? I haven't seen this behavior before, and it's somewhat disconcerting. Any ideas?
The Get was just a manual get using the GUI. I go to "show labels" on the folder, right click the label I want and then do a "get". Get by label always sets overwrite to true, and the only other updated setting was that I set the file date to "modified date" from "current date" in the Get dialog. However, I also tried just using the defaults and got the same behavior both ways.
FYI: I am using remote desktop to get to my build machine.
I also noticed some other strange behavior that I've seen before, perhaps it's related. Might just be a refresh thing via remote desktop, but often times when I do a get, the progress bar gets all the way to 99% complete, and just hangs at that point indefinitely even though it appears to be finished. I'll follow up by doing another get and it will go all the way through without incident. I did experience this behavior today. Is it possible that it's updating some internal state so that it thinks it has the correct version, but didn't acutally complete the operation?
FYI: I am using remote desktop to get to my build machine.
I also noticed some other strange behavior that I've seen before, perhaps it's related. Might just be a refresh thing via remote desktop, but often times when I do a get, the progress bar gets all the way to 99% complete, and just hangs at that point indefinitely even though it appears to be finished. I'll follow up by doing another get and it will go all the way through without incident. I did experience this behavior today. Is it possible that it's updating some internal state so that it thinks it has the correct version, but didn't acutally complete the operation?
The progress bar problem does sound suspicious, and if the local machine has stored the wrong versions of files, that would certainly cause problems.
We should probably verify this a client side issue. If you do the exact same get by label with the same user name on a different machine, does it work? If so, it is likely tied to the client cache.
Also, you could try a Get Latest, overwrite, on the problem machine, verify via the search pane that all files are current, and then try the label Get again.
Also, another thing to note: A status of Old after a label get may be correct, if someone else has checked in a file since the label was applied. That doesn't sound like it happened here, but might be good to verify.
We should probably verify this a client side issue. If you do the exact same get by label with the same user name on a different machine, does it work? If so, it is likely tied to the client cache.
Also, you could try a Get Latest, overwrite, on the problem machine, verify via the search pane that all files are current, and then try the label Get again.
Also, another thing to note: A status of Old after a label get may be correct, if someone else has checked in a file since the label was applied. That doesn't sound like it happened here, but might be good to verify.
In this case, I knew that I should have had the tips of all the files on this branch, but I understand that if a checkin had been done after the label that this could be a correct status.
I did go ahead and do a get latest before building because I knew I was dealing with the tips of the branch in all cases for the build, and felt it was safest just to go this route to ensure I had the latest of all files, so this has already been done. This appeared to pull any lingering files that weren't being pulled by the label, but may make it impossible to reproduce the error on the build machine.
Should this refresh the local cache, or is there something else I should to to make sure it has been flushed?
I did go ahead and do a get latest before building because I knew I was dealing with the tips of the branch in all cases for the build, and felt it was safest just to go this route to ensure I had the latest of all files, so this has already been done. This appeared to pull any lingering files that weren't being pulled by the label, but may make it impossible to reproduce the error on the build machine.
Should this refresh the local cache, or is there something else I should to to make sure it has been flushed?
To make absolutely sure the local cache is correct, you could simply delete it and it will recreate itself. However, you'd need to recreate working folders and such.
See http://support.sourcegear.com/viewtopic.php?t=6 for a good explanation of the cache files.
We use the label and get by label commands here for our own builds, so I'd be surprised if there were something very basic wrong with it. However, it would be good to verify that when you label the next time, it works ok for you, and this was some kind of aborted Get problem, which would still be important, but not as bad as a problem with get by label.
See http://support.sourcegear.com/viewtopic.php?t=6 for a good explanation of the cache files.
We use the label and get by label commands here for our own builds, so I'd be surprised if there were something very basic wrong with it. However, it would be good to verify that when you label the next time, it works ok for you, and this was some kind of aborted Get problem, which would still be important, but not as bad as a problem with get by label.
Here is a screenshot of what I see after I do a get by label. You can see that the status bar says "ready". However, the progress bar never resets. It just sits indefinitely at 99%. Is this just a rendering issue with the progress bar, or is something really not finishing?
- Attachments
-
- shot.jpg (161.3 KiB) Viewed 7555 times