Checkins to Vault thwarted when attempted via VS.NET 2003
Moderator: SourceGear
Checkins to Vault thwarted when attempted via VS.NET 2003
This may be a common problem but we have just installed FogBugz 4.0 for Windows and are in the process of integrating it with our existing SourceGear Vault v3.1.2 and MS Visual Studio C#.NET 2003v7.1. We have had no problems thus far between FogBugz and Vault. Checkins & checkouts via Vault client seem to be working as advertised with FogBugz in terms of enforcing a valid case id on checkin. However, when our developers have attempted to do the checkins within the VS.NET environment, we get the following error after entering a valid case # on the popup: "You have not entered any valid Bug ID values. A valid Bug ID is required for checkins to this repository." The checkin cannot proceed via VS.NET IDE and we must use the Vault GUI. Is this a Vault or VS.NET configuration issue? Does Vault expect a Dragnet type case number? Any help would be appreciated. Thanks.
Checkins thwatred in VS.NET
Jeff,
Thanks for the quick response. However, the dialog that comes up as a result of your suggestion is the same one (Update Bugs) that is coming up automatically for us at checkin which is not accepting the case ids we enter. So I get the same "error" blocking the checkin. In VS.NET Tools->Options... there is a folder called Source Control. We have ours set to Visual SourceSafe (even though we are using SourceGear). Is there anything under this folder that we might need to adjust? Or in the General or SCC Provider subfolders? Under General we have nothing checked and "Prompt for checkout" for both drop downs.
Thanks again.
Jeff S.
Thanks for the quick response. However, the dialog that comes up as a result of your suggestion is the same one (Update Bugs) that is coming up automatically for us at checkin which is not accepting the case ids we enter. So I get the same "error" blocking the checkin. In VS.NET Tools->Options... there is a folder called Source Control. We have ours set to Visual SourceSafe (even though we are using SourceGear). Is there anything under this folder that we might need to adjust? Or in the General or SCC Provider subfolders? Under General we have nothing checked and "Prompt for checkout" for both drop downs.
Thanks again.
Jeff S.
Re: Checkins thwatred in VS.NET
I have my settings at "Custom", although I don't think using "Visual SourceSafe" would hurt.jcsteele wrote:We have ours set to Visual SourceSafe (even though we are using SourceGear). Is there anything under this folder that we might need to adjust? Or in the General or SCC Provider subfolders? Under General we have nothing checked and "Prompt for checkout" for both drop downs.
Can you check the Repository Options within the Vault Admin Tool? Double check the Bug Tracking App is set to FogBugz and the Bug Tracking URL is correct.
Additionally, you could try "unchecking" the Require Bug ID for Checkins, and try to update a few bugs. If the FogBugz item is not being updated on checkin, then it could be the URL used to interop with FogBugz is incorrect.
Jeff Clausius
SourceGear
SourceGear
Checkins thwarted using VS.NET
Jeff,
Our Repository Options in the Admin Tool appear correct. FogBugz is selected and the URL is accurate. Again, FogBugz/Vault integration is working so I don't believe there is a misconfiguration in that area. When checkins are done via Vault we see the files being listed in the FogBugz cases. So I'm unclear about what is learned if I uncheck the "Require Bug ID for checkins" as you suggested if the URL is used between FogBugz and Vault. I tried changing from Use Visual SourceSafe to Use Custom Settings in VS.NET options but when I reaccess the options screen the selection is set back to SourceSafe so that change is not "taking".
Our Repository Options in the Admin Tool appear correct. FogBugz is selected and the URL is accurate. Again, FogBugz/Vault integration is working so I don't believe there is a misconfiguration in that area. When checkins are done via Vault we see the files being listed in the FogBugz cases. So I'm unclear about what is learned if I uncheck the "Require Bug ID for checkins" as you suggested if the URL is used between FogBugz and Vault. I tried changing from Use Visual SourceSafe to Use Custom Settings in VS.NET options but when I reaccess the options screen the selection is set back to SourceSafe so that change is not "taking".
There was a bug (that was fixed in Vault 3.1.3) that caused bug validation for Fogbugz to always fail in the IDE. If you are using a version of Vault prior to 3.1.3, you should upgrade to the current version.
Or you can turn off the "Require bug ID for checkin" option in the Admin Tool. The bugs should be updated if you uncheck this option since the validation check that was causing the problems with the IDE only occurred if you have this option on.
Or you can turn off the "Require bug ID for checkin" option in the Admin Tool. The bugs should be updated if you uncheck this option since the validation check that was causing the problems with the IDE only occurred if you have this option on.
Mary Jo Skrobul
SourceGear
SourceGear
VS.NET thwarts checkins
I upgraded my Vault client to 3.1.5 and the checkins proceed without error from VS.NET IDE now. So thank you. My only concern is that now we get a warning/alert under the Vault Messages area stating: "Version Check: SourceGear recommends that the client and server be the same version". Our server version is 3.1.2.3511. Upgrading our server requires more red tape since it is not directly under our control. Is it strongly recommended or necessary that we upgrade? Thanks.
Of course it is always *recommended* that the Server and the Client are the same version, but a 3.1.2 server will work fine with 3.1.5 clients so there shouldn't be an urgent need to upgrade your server.
If you want to turn off the warning you can do it in the client options (tools->options->general).
If you want to turn off the warning you can do it in the client options (tools->options->general).
Mary Jo Skrobul
SourceGear
SourceGear
VS.NET thwarts checkins
Thanks very much, Mary Jo. I believe our issue has been fully addressed.