2.0.4 problems

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
billb
Posts: 2
Joined: Wed Jul 21, 2004 9:06 pm

2.0.4 problems

Post by billb » Wed Jul 21, 2004 9:15 pm

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?

young

Same problem plus

Post by young » Wed Jul 21, 2004 9:25 pm

Having the same problem, but having it in both the VS IDE and the Vault client.

2.0.4 client and server.

amaia
Posts: 2
Joined: Wed Jun 30, 2004 6:47 am

Post by amaia » Thu Jul 22, 2004 8:39 am

I have the same problem.

The problem is resolved when remove the file CacheMember_Repository in profile of users.

It's possible to add an option to flush completly this cache in client software in the future release ? There are many problems with this file.

young

well, this seemed to work for a while

Post by young » Tue Jul 27, 2004 3:09 pm

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.

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Tue Jul 27, 2004 3:30 pm

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.

young

answers

Post by young » Tue Jul 27, 2004 10:01 pm

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.

Guest

Post by Guest » Tue Jul 27, 2004 10:25 pm

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.

sterwill
Posts: 256
Joined: Thu Nov 06, 2003 10:01 am
Location: SourceGear

Post by sterwill » Wed Jul 28, 2004 11:39 am

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]
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`

young

thank you

Post by young » Wed Jul 28, 2004 8:40 pm

will install and begin using this tommorow and send a report.

sterwill
Posts: 256
Joined: Thu Nov 06, 2003 10:01 am
Location: SourceGear

Post by sterwill » Thu Jul 29, 2004 9:22 am

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.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`

Post Reply