VS2003.Net and using vault for same user from multiple PCs

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

Moderator: SourceGear

Post Reply
Pawan
Posts: 19
Joined: Wed Apr 28, 2004 12:46 am

VS2003.Net and using vault for same user from multiple PCs

Post by Pawan » Tue Jan 25, 2005 5:11 pm

Hi,

I am using Visual Studio .Net 2003 with Vault client 2.0.6.

I want to work on two different machines on the same visual studio project. One machine I am changing file "a.vb" and on another machine I am changing "b.vb" file in the same project. Unfortunately, vault integration keeps on telling me that both files are checked out on both machines which is incorrect. Sometimes, when loading the project, it gives bizarre source control errors which causes Visual Studio to crash.

Is this mode of operation supported? Is there any fix or workaround for it?

Thanks
Pawan

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

Post by dan » Tue Jan 25, 2005 5:13 pm

This mode is supported, so it is a question of why both files get checked out.

Open up the Vault GUI client and when you check out a file in the IDE, do a refresh in the GUI client and see what actually happened - at what point are both files checked out?

Pawan
Posts: 19
Joined: Wed Apr 28, 2004 12:46 am

Post by Pawan » Tue Jan 25, 2005 5:39 pm

When I get latest on another machine and open the project, the files are shown as checked out. I can even select "Show pending checkins" in Visual studio and it shows the files which are checked out on another machine. If I do diff with the repository, these files are identical.

Doing a refresh does not seem to change a thing.

-Pawan

Pawan
Posts: 19
Joined: Wed Apr 28, 2004 12:46 am

Post by Pawan » Tue Jan 25, 2005 5:41 pm

By refresh, I mean refresh in Visual Studio.

In Vault client, it always shows checked out files for the other users - so it is OK for it to show that the file is checked out by me (it would be nice if it showed machine name along with it - so that I know that I checked out that file on that machine).

I think the problem is that with Visual Studio integration, Visual Studio may not be asking vault correctly or the vault api may have a bug in it.

-Pawan

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

Post by dan » Tue Jan 25, 2005 8:30 pm

So, just to verify, when you check out the one file in Visual Studio, it also checks out the other file? Does this happen everytime for those two files, or is there something else that happens in-between?

Visual Studio does automatically check out .resx files when .cs or .vb files are checked out - perhaps there is confusion there. Does it happen for just those two files mentioned, or does it happen on other files too?

If this happens for everyone on the team, you might consider sending us the project/solution - you could erase the actual content of the files, as it probably doesn't have anything to do with contents of the file - just their configuration. If we could reproduce it here, we could tell whether the problem is Visual Studio or Vault.

Pawan
Posts: 19
Joined: Wed Apr 28, 2004 12:46 am

Post by Pawan » Tue Jan 25, 2005 8:58 pm

Sorry - I think I am not clear in my query. Here is the problem again.

1. Create a solution A in Visual studio and create a project X in it. Add two files in it "a.vb" and "b.vb". Add the whole solution to Source control.

2. Go to PC1 and login as USER1 and get this solution from source control. Checkout a.vb. Make some changes.

3. Go to PC2 and login again as USER1. Get this solution from source control. Visual studio will show you in this project that a.vb is checked out. It is incorrect. Because this file is not same as PC1. This is so bad that you can even check this file in!!!

For both PCs, user logged in USER1 is using USER1 on vault server.

So it seems like Vault cannot differentiate that for the same user on different PCs, a file can be checked out idependently.

-Pawan

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

Post by dan » Wed Jan 26, 2005 8:43 am

OK, I see. Yes, this is just how it works in the IDE. The Vault GUI client should work correctly in this case.

Pawan
Posts: 19
Joined: Wed Apr 28, 2004 12:46 am

Post by Pawan » Wed Jan 26, 2005 11:04 am

But we are used to selecting "Show pending checkins" in Visual Studio and checking everything in. This screws up the checkouts on another machine. Why can't VisualStudio+Vault integration distinguish that the checkout is on another machine and not show that the file is checked out?

Is there a way I can fix it - by setting some registry keys?

Thanks
Pawan

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

Post by dan » Wed Jan 26, 2005 11:35 am

It looks like what is happening is that the checkin from the 2nd machine is undoing the checkout on the 1st machine. Although, it does seem smart enough to know whether the files on the 2nd machine are actually modified, and if they aren't, it undoes the checkout rather than doing an empty checkin.

I'll add this an enhancement, but unfortunately for now, there isn't much of a work-around other than not checking in the files that aren't checked out on that machine.

Pawan
Posts: 19
Joined: Wed Apr 28, 2004 12:46 am

Post by Pawan » Wed Jan 26, 2005 4:08 pm

But in a large project, you do not know which one is not checked out on this machine. There is no hint in Visual studio about which file is checked out on another machine.

It is worse than that. I cannot checkout the file on the second machine to work on it through Visual Studio because it thinks the file is already checked out.

Funny thing is: using Visual Source Safe, it works perfectly. So there is something broken with Vault. It is not an enhancement - but a bug. Is it possible to get this bug fixed in the next release?

-Pawan

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

Post by dan » Wed Jan 26, 2005 5:08 pm

You could undo the checkout from the 2nd machine and then check it out if you need to make changes.

Yes, this is a problem, and we will look at it, but can't promise whether it will make the next release or not.

Post Reply