Collaborative Development w/IDE Integration

bsapd · Post by **bsapd** » Fri Apr 23, 2004 8:56 am

I have just moved a project from VSS to Vault that has three developers working on it. For the most part everything went well.

One of the developers keeps his working directory in a different location than the other two. The two developers that use the same structure are having no problems. The other one gets lots of strange behaviors like, checkout icons not changing after check in and backup files made on every checkout.

I had the third developer switch to the same structure as the others and everything worked fine.

He is obviously not happy having to change from what he is used to.

Does anyone know what the problem here is? Is it fixable?

Visual Studio 2003; Vault 2.02; .Net 1.0 and 1.1

dan · Post by **dan** » Fri Apr 23, 2004 9:15 am

There's no requirement that all developers use the same working folder location on their local machines, so there is likely something else going on.

Is this a web project? I think VS requires that web projects have a hardcoded URL, but that can be worked around using IIS virtual folders.

If files are being backed up on checkout, the problem might be that the files were Unknown on the developers machine. Doing a Get Latest will correct that, and after that, everything would work fine.

bsapd · Post by **bsapd** » Fri Apr 23, 2004 12:07 pm

There are two web projects in the solution and four non-web projects. Is there something I can check for? We did get latest version from within the IDE but not the client, would that make a difference?

dan · Post by **dan** » Fri Apr 23, 2004 12:38 pm

You can check for the Unknown status from the GUI client, but a Get with overwrite or attempt auto merge should work to get rid of the Unknown status from any client.

bsapd · Post by **bsapd** » Fri Apr 23, 2004 1:01 pm

The status on the files is blank not missing. And now the rest of the team is experiencing similar issues. The integration seems to be working (the files are actually being checked out and changes are being saved) but the icon stays checked out after checking and backup copies are being made. Something is not right.

dan · Post by **dan** » Fri Apr 23, 2004 1:28 pm

Are the files in question read-only, or are they read-write? A read-write file will appear as checked out in VS, even if it isn't checked out in Vault.

Also, are there any files with a non-blank status in Vault in any of the project folders?

Another thing to try: If you start completely fresh and do an Open From Source Control from within the IDE to an empty set of working folders, is it any better?

bsapd · Post by **bsapd** » Fri Apr 23, 2004 2:14 pm

Recreating the solution from source control has helped for one of my guys. I don't think it is a reasonable solution to have to periodically recreate the solution however.

When looking at the physical files they are not read-only. The option to leave files checked out is off. The vault client says the file is checked in but VS says it is checked out. When manually making the file read-only VS shows the right icon. But then checking the file out and in again the file stays read-write.

Also, the solution file and project files keep showing up as renegade in the client...

dan · Post by **dan** » Fri Apr 23, 2004 2:54 pm

OK, at least we are making some progress in understanding this. VS considers any file that is read-write as checked out, which is why the file is showing up as checked out. The question is why the files are read-write after a checkin.

Check your Vault option Tools->options->local files->Make writable. It should be set to make all files read-only.

As for the project/solution files - have they actually changed? Vault will mark them as Renegade if their datetimes have changed since the last time it retreived them (and if they are not checked out). Is VS modifying those files, but not checking them out?

One other thing to check is the MSSCCPRJ.SCC file in each local project directory. It stores the bindings for how to connect to Vault. Check to make sure they seem to have reasonable values.

bsapd · Post by **bsapd** » Fri Apr 23, 2004 3:19 pm

The option Tools->options->local files->Make writable is set to make all files read-only.

VS is definitely changing the files and not checking them out... see the attachment to see the differences.

I have also added some other source control files in the attachment.

dan · Post by **dan** » Fri Apr 23, 2004 3:42 pm

Hmm. The files aren't really giving me much info. What is happening when the files go renegade, but are not checked out? In Visual Studio options->Source Control->General, what is it set to do when checked in items are edited or when checked in items are saved?

bsapd · Post by **bsapd** » Fri Apr 23, 2004 3:59 pm

The setting is set to undo checkout. VS does nothing with the solution and project files but it runs an undo checkout on the files that were not marked read-only.

dan · Post by **dan** » Mon Apr 26, 2004 7:32 am

bsapd wrote:The setting is set to undo checkout. VS does nothing with the solution and project files but it runs an undo checkout on the files that were not marked read-only.

We may not be talking about the same options. Look in Visual Studio->Tools->options->Source Control->General, and look at the two options with drop down values. What are those set to?

bsapd · Post by **bsapd** » Mon Apr 26, 2004 7:46 am

In VS none of the check boxes are checked and both drop downs are set to "Prompt for check out".

dan · Post by **dan** » Mon Apr 26, 2004 8:03 am

So, the mystery here is why the files are in a read-write state. After they get checked in to Vault, or retrieved by Vault, their state should be read-only on any machine where the logged in user has the Vault option "Make writable" set to "Make all files read-only" (which is hardcoded to be that when the operations are performed from the IDE).

You should not have to do an Open From Source Control periodically. Doing it the first time should have set the files to read-only state. Since the problem appears to be the readability flag, getting them all set back to read-only should fix the problem.

If you can figure out when the files become read-write, that would help in determining what program is doing it, and perhaps why.