I just checked out a file from Visual Studio and modified it.
I then switched to the Vault GUI client (which was running) and went to commit my changes (to that file as well as some others).
That file was not listed in my pending changeset! When I went to see what the Vault client thought the status of that file was, it was displayed as Renegade!
When I hit F5 (refresh) the status updated to Edited.
This is a little worrisome.
Mike
Checked out file displayed as Renegade
Moderator: SourceGear
This behavior should be expected when mixing between VS.Net and Vault GUI, you must take care to refresh your pending changes.
While the Vault GUI and VS.Net / Vault IDE clients both written to interoperate, neither contain code for IPC or a way to automatically detect when one client updates the Pending Changes of the other.
In the case you mentioned, VS.Net wrote out its pending changes, and when you refreshed (F5), the GUI client detected the new change. Also, if you had committed your changes, the GUI client forces a refresh, so the file would have shown up in the Commit dialog.
While the Vault GUI and VS.Net / Vault IDE clients both written to interoperate, neither contain code for IPC or a way to automatically detect when one client updates the Pending Changes of the other.
In the case you mentioned, VS.Net wrote out its pending changes, and when you refreshed (F5), the GUI client detected the new change. Also, if you had committed your changes, the GUI client forces a refresh, so the file would have shown up in the Commit dialog.
Jeff Clausius
SourceGear
SourceGear
Except that I did do a commit all and the file didn't show up in the commit dialog! Only the files listed in the pending changeset window showed up.
It really seems reasonable to expect that the pending changeset window will reflect ALL files checked out in your working folder when it is the active window in the foreground application, regardless of what application actually checked out the file.
Mike
It really seems reasonable to expect that the pending changeset window will reflect ALL files checked out in your working folder when it is the active window in the foreground application, regardless of what application actually checked out the file.
Mike
My apologies. The client's behavior is on par with Microsoft's VS.Net. For example, if you check out a file within the Vault GUI, VS.Net does not detect the file has been locked until specifically told to rescan.
I'll check with the client team, but my guess is a re-scan would be costly, so the change set is does not try to detect any changes made outside its own process.
I'll log an investigatory request to see if anything can be done in this area.
Thanks for the feedback.
I'll check with the client team, but my guess is a re-scan would be costly, so the change set is does not try to detect any changes made outside its own process.
I'll log an investigatory request to see if anything can be done in this area.
Thanks for the feedback.
Jeff Clausius
SourceGear
SourceGear
Yeah, but we both know that VS.NET source control handling sucks 
However, although the results of a rescan would be optimal, I don't think that is required in this particular case. I'm not expecting the main window to reflect the current checked out/edited status w/o a manual refresh, just the pending changeset window.
And this is not the other issue of allowing check ins w/o check outs and having to do a rescan to find all of the modified files. The files I'm talking about are actually checked out.
I believe that there is a cache of checked out files kept somewhere, so all that should be required is to have the code that supports the pending changeset window verify that all checked out files are listed when it is activated (either by selecting the tab or by the tab being active when the application gets a WM_ACTIVATEAPP or the window gets a WM_ACTIVATE message, I'm not sure which is most appropriate).
And it sounds like you expected the file to have been in the Commit dialog when I did a commit all, and it wasn't.
Mike
However, although the results of a rescan would be optimal, I don't think that is required in this particular case. I'm not expecting the main window to reflect the current checked out/edited status w/o a manual refresh, just the pending changeset window.
And this is not the other issue of allowing check ins w/o check outs and having to do a rescan to find all of the modified files. The files I'm talking about are actually checked out.
I believe that there is a cache of checked out files kept somewhere, so all that should be required is to have the code that supports the pending changeset window verify that all checked out files are listed when it is activated (either by selecting the tab or by the tab being active when the application gets a WM_ACTIVATEAPP or the window gets a WM_ACTIVATE message, I'm not sure which is most appropriate).
And it sounds like you expected the file to have been in the Commit dialog when I did a commit all, and it wasn't.
Mike