Vault and Vs2005 interactions

Gary_Berg · Post by **Gary_Berg** » Fri Oct 05, 2007 11:44 am

We're testing Vault to work with VS2005; we're testing v 4.04. We've got a few interactions that are "interesting" I'd like to ask about:

1) First, we have a hierarchy of one main solutions, with multiple folders underneath it.

2) We've got at least one developer who found, when he associated some folders in the repository that the rest were pulled down to his system. What settings would have caused this and how can it be controlled?

3) We find that VS will check out the project file at the drop of a hat, sometimes even just opening the project will do it. In fact, once I opened our main solution (contains 12 csproj files) and it was insistent on checking out two particular project files. They kept reappearing in the list of items pending checkin (inside VS), even when I checked them in they would reappear. Is there a better way to control this?

4) In an ideal world, we'd like to have to explicitly check each file or project file out of the repository, work on it, and manually check it back in. From within the IDE, if possible. The automatic check out is nice, but not really necessary - and it can be confusing with more than one person working on a project. I read some comments here about a "check out on edit" setting, but I could not find this in the VS2005 SP1 IDE. I am using the VS2005 interface to Vault.

5) Vault seems to consider VS project files as binary; they look to be XML, which isn't really binary. This makes it harder to handle resolving any conflicts. Are there reasons why they are treated as binary or is it just that the first 2-3 characters of an XML file make it look binary?

Any feedback on this?

ian_sg · Post by **ian_sg** » Fri Oct 05, 2007 12:31 pm

Gary,

Thanks for the feedback. I make several references below to the 2003-compatible plugin. Note that despite its name, it plays nicely under 2005.

1-2) I'm not sure I understand this question. Some source you did not expect to be retrieved was retrieved, but beyond that I don't understand the setup. Can you provide some more detail?

3) Visual Studio frequently wants to make meaningless changes to project files, for which we do an automatic checkout. We're investigating options for improving this. For one, we intend to add a "Confirm Checkout" option in the future which will help. This option is already available in the 2003-compatible client.

4) This too sounds like confirming checkouts and/or disabling automatic checkouts would work best for you. Check out the 2003-compatible client, as it may meet your needs better at this point.

5) Vault keeps a list of mergeable file extensions for each repository. By default, project files are not part of this list. If you would prefer that project files be treated as mergeable, you can can the relevant file types (e.g. csproj, vbproj) to that list via the administrative web interface.

Gary_Berg · Post by **Gary_Berg** » Fri Oct 05, 2007 1:12 pm

ian_sg wrote:1-2) I'm not sure I understand this question. Some source you did not expect to be retrieved was retrieved, but beyond that I don't understand the setup. Can you provide some more detail?

Basically, that's the problem. Some source was retrieved that was not explicitly requested. The project is arranged as:

Main Project Folder
----project1
----project2
----project3
----project4

(project<n> is the VS project file and its associated source files). I assume he associated the main project folder with the main project in the repository, but I also assume he didn't click "get latest version" either.

He had project2 and 4. And some time while he was working in VS2005 and probably had the client open it copied down the files in project1 and 3. This made him really nervous.

Also, if VS2005 sometimes makes meaningless changes to the files, how do I know if it's meaningless, so I can tell it to revert?

Your reply makes me conclude that the 2003 client is probably my best choice. My 3 developers are currently all using the 2005 value client inside VS2005. How do I switch "down" to the 2003 version?

ian_sg · Post by **ian_sg** » Mon Oct 08, 2007 7:56 am

I see. When you bind a solution/project on disk to Vault and set a working folder, the current release does a Get Latest to get baseline files up to date and get valid file statuses. That's probably what happened here.

The next maintenance release, due out very soon now, is smarter in this scenario and doesn't have to perform an unrequested Get Latest.

Gary_Berg · Post by **Gary_Berg** » Mon Oct 08, 2007 8:55 am

Ian,

Your earlier post makes it appear that my best bet is to switch my developers back to the 2003 interface, as it supports explicit checkouts better. I toyed with this a little with a sample project and eventually had everything confused.

With the 2003 interface, what happens when VS2005 decides it wants to make a meaningless change to the project file? Does it ask me? Do I get a good indication of what the changes it wants to make are?

Do you have a document about how to switch from the 2005 to 2003 interface? I know you have one going the other way, but I wasn't sure if I could just exchange all 2003/2005 references or not.

Gary Berg

ian_sg · Post by **ian_sg** » Mon Oct 08, 2007 9:17 am

The spurious changes to project files are a little frustrating as we can't prevent them in either client. In the 2003 client, however, there is an option to prompt you whenever a checkout is about to occur, so you get a chance to prevent it. You don't get a chance to preview the change that's about to be made, but it's generally pretty obvious, as you haven't done anything that would require a change.

We don't have a document that explicitly details the steps to move from the 2005 client to the 2003, but the existing kb article works in reverse:

1. Unbind from the 2005 client
2. Switch the active provider
3. rebind using the 2003 client
4. checkin changes

Gary_Berg · Post by **Gary_Berg** » Mon Oct 08, 2007 1:38 pm

Ian,

I'm having a lot of trouble consistently changing VCS. I sometimes get into a mode where Vault inside of VS2005 is "annoyed" and gives error messages.

I tried stepping my way through the KB article after getting a project stuffed into Vault when using the 2003 client. So I unbind, change source control, save all, and I'm ready to bind. Hmm, "bind" is not a choice when I right-click the .SLN file. I've got Vault 4.0.4 installed - has this changed? I had a choice to Add to Vault, but Bind was either not there or greyed out.

I'm trying to get comfortable with making a switch from the 2005 VS client to the 2003 client. I do NOT get a warm fuzzy feeling right now...

I finally cleaned out the Vault folders down deep in my Windows profile folders; that at least got me past some of the error messages.

I've got a test project that's not in the vault, which I'm trying to add. I right-click, choose Add to Vault, log in, and get the "infamous" sourcgearllp.vaultvsipclient.vsiputility+assertionfailedexception.

This is Vault 4.0.4, VS 2005 with SP1.

ian_sg · Post by **ian_sg** » Tue Oct 09, 2007 8:21 am

In the 2003-compatible client, the bind/unbind options are under File->Source Control->Change Source Control...

However, it sounds like you're in a "partially bound" state. After unbinding from the 2005 client, the only option on the right-click menu should be "Add Solution to Vault." Are you seeing that?

Gary_Berg · Post by **Gary_Berg** » Tue Oct 09, 2007 8:45 am

Yes, it sounds like things may be partially bound in this case. I have a "Add Solution to Vault" option. The working directory in the Vault client software is set properly.

When I try to add the solution to vault, after logging in, it dies with the exception I mentioned.

How do I get from a partially bound state to a fully bound state (or back to unbound and then bind it again)?

ian_sg · Post by **ian_sg** » Wed Oct 10, 2007 8:02 am

Manually unbinding from the 2005 client involves removing some data from project and solution files. In the solution file, you want to remove the section that looks like this:

Code: Select all

	GlobalSection(VaultVsipSolution-v1) = preSolution
		VaultHost = http://localhost/VaultService
		VaultRepositoryID = 2
		VaultRepositoryGUID = 7eb56c34-4fc7-4fae-bdbe-d732b77a54f1
		ProjectCount = 5
		ProjectRelativeDiskPath1 = ClassLibrary1\ClassLibrary1.csproj
		ProjectRelativeDiskPath2 = WindowsApplication43\WindowsApplication43.csproj
		ProjectRelativeDiskPath3 = WindowsApplication43.sln
		ProjectRelativeDiskPath4 = WindowsApplication43.sln
		ProjectRelativeDiskPath5 = Setup1\Setup1.vdproj
	EndGlobalSection

In project files, there are 4 lines to remove:

Code: Select all

<SccProjectName>GetTestSolution1</SccProjectName>
<SccLocalPath>2~7EB56C34-4FC7-4FAE-BDBE-D732B77A54F1</SccLocalPath>
<SccAuxPath>http://localhost/VaultService</SccAuxPath>
<SccProvider>SourceGear Vault Visual Studio 2005 Client:{7BE9CE03-56BF-4682-9C06-78C68B134B30}</SccProvider>

Gary_Berg · Post by **Gary_Berg** » Wed Oct 10, 2007 8:48 am

Ian,

OK, after I do the above I've got a project in Vault, with a local, un-bound copy on my local HD. What's the cleanest way to connect them (in the Vault client the working directory still matches up)?

1) Add Solution to Vault?

2) Open Solution from the Vault and put it in the local folders?

3) ???

ian_sg · Post by **ian_sg** » Wed Oct 10, 2007 8:54 am

If the code already exists in the repository, there's two ways, regardless of the client you're using:

1) Bind
2) Open From Vault (after clearing a space on disk)

If you want to stick with the 2005 client, I highly recommend checking out the 4.0.5 beta we just released, as its got vastly improved binding support. If you do, be aware that the bind functionality is now accessed under File->Change Vault Bindings.