2.0.4 problems
Moderator: SourceGear
2.0.4 problems
Something is broken with the check in and undo check out from a visual stand point. About 75% of the time when I check in or undo a check out from either the IDE or the client itself, the change is not reflected in the UI, even thought the action has been performed. In the IDE, I need to close and re-open the solution and in the client, I need to change repositories and switch back to have things updated properly.
Also, I thought I read that undoing is supposed to automatically revert (or revert by default) as of 2.0.4? It doesn't seem to revert, which is the behavior that I would expect. Otherwise, if I'm in the IDE and I undo a check out, I have to then load up the client and grab the latest version in order to truly get my changes undone.
Can anyone shed some light on what's going on here?
Also, I thought I read that undoing is supposed to automatically revert (or revert by default) as of 2.0.4? It doesn't seem to revert, which is the behavior that I would expect. Otherwise, if I'm in the IDE and I undo a check out, I have to then load up the client and grab the latest version in order to truly get my changes undone.
Can anyone shed some light on what's going on here?
Same problem plus
Having the same problem, but having it in both the VS IDE and the Vault client.
2.0.4 client and server.
2.0.4 client and server.
well, this seemed to work for a while
But now having the same problem again. File was not recreated or anything. Anyone from sourcegear care to address/acknowledge this or suggest a more sustainable solution to the problem?
Not knowing what files are checked in/out is really starting to waste a lot of my time.
Not knowing what files are checked in/out is really starting to waste a lot of my time.
This is the first we've heard of reports like this for 2.0.x (there were some circumstances back in 1.X version where this could happen, but those reports have all been addressed).
We would need more localization of the problem to figure out what is going on. Some ideas:
1. Does the server log indicate that there is a problem on checkout/checkin or undo checkout?
2. The checkout status in the IDE can often be incorrect, because the IDE determines checkout status not by querying Vault, but by checking whether the file is read-only. So, try to stay within the GUI client to determine if the problem is Vault.
3. When this happens, fire up another client on a different machine and see whether the checkout status is the same or not.
4. If you can reproduce this reliably, we'd obviously want to try to get it to happen here too.
We would need more localization of the problem to figure out what is going on. Some ideas:
1. Does the server log indicate that there is a problem on checkout/checkin or undo checkout?
2. The checkout status in the IDE can often be incorrect, because the IDE determines checkout status not by querying Vault, but by checking whether the file is read-only. So, try to stay within the GUI client to determine if the problem is Vault.
3. When this happens, fire up another client on a different machine and see whether the checkout status is the same or not.
4. If you can reproduce this reliably, we'd obviously want to try to get it to happen here too.
answers
1. No. The checkins actually go off without a hitch, just that the client does not show that they have been checked in.
2. This happens in the vault client, not always, but often. Happens more often in the IDE, but it did not happen until recently.
3. I will, but I can tell you that most likely it will show you the proper checked in state. Changing repositories away from current and back shows the proper state on changeback. It seems to be a visual only. Something else odd, that I think might be related, is that the client will show multiple checkouts to the same person.
4. I'll work on a reliable way to reproduce it.
2. This happens in the vault client, not always, but often. Happens more often in the IDE, but it did not happen until recently.
3. I will, but I can tell you that most likely it will show you the proper checked in state. Changing repositories away from current and back shows the proper state on changeback. It seems to be a visual only. Something else odd, that I think might be related, is that the client will show multiple checkouts to the same person.
4. I'll work on a reliable way to reproduce it.
Dan, I just did some checkins from VS.NET (2003, BTW) and then went into the Vault client and did a View->Refresh. The files still show as checked out.
Terminal serviced into a different box, fired up a copy of the vault client, and looked. Shows the same filed as checked in + OLD (which is correct).
No amount of view->refresh will make the borked client realize that these files are checked in. One odd thing, though it does NOT show them as edited (which they were before the checkin) and DOES show the proper versions for both remote and local.
Right clicking on these items DOES give me the option to check in. This displays a message of '[7/28/2004 12:24:28 AM] Undoing check out of file $/eps_development/TIPSImports/RecipeBaseDataImport.aspx.resx', but does NOT update the client to show the file is not checked out any longer.
Assuming the reason it is showing an undo checkout is because you do a diff and if there are none, compared to tip you simply undo the checkout.
Terminal serviced into a different box, fired up a copy of the vault client, and looked. Shows the same filed as checked in + OLD (which is correct).
No amount of view->refresh will make the borked client realize that these files are checked in. One odd thing, though it does NOT show them as edited (which they were before the checkin) and DOES show the proper versions for both remote and local.
Right clicking on these items DOES give me the option to check in. This displays a message of '[7/28/2004 12:24:28 AM] Undoing check out of file $/eps_development/TIPSImports/RecipeBaseDataImport.aspx.resx', but does NOT update the client to show the file is not checked out any longer.
Assuming the reason it is showing an undo checkout is because you do a diff and if there are none, compared to tip you simply undo the checkout.
I've created a 2.0.5 preview 2200 build with extra logging facilities for the check out list. You can find the build here (file at URL may disappear as it becomes obsolete). Read this knowledge base article to enable logging. Once you reproduce the problem, send the log file to me and note the exact time you reproduced the problem. My e-mail address is RATsterwill@sourcegear.com (remove the rodent).
[edited by sterwill: added build number to differentiate from other 2.0.5 previews]
[edited by sterwill: added build number to differentiate from other 2.0.5 previews]
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
Just as a reminder, if you have any firewall (including "personal" firewall products), proxy (Microsoft ISA, Squid, etc.), filtering, or rate limiting software installed on or between your Vault client and server, please reveal this in any messages you post to the support forums or send to our support e-mail address. We've had dozens of reports in the past of client lockups, socket data corruption, dropped connections, and similar problems that disappeared when the third-party network software was disabled.
Vault clients communicate with the server exclusively through the .NET web request and HTTP library implementations. In most cases of trouble at these levels, we can do little to diagnose the problems.
Vault clients communicate with the server exclusively through the .NET web request and HTTP library implementations. In most cases of trouble at these levels, we can do little to diagnose the problems.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`