We just migrated a large solution (7) projects to Vault. When we try to do do a multiple checkout of any .csproj file, both the Vault client and the IDE client tell us that the file is already checked out and we can't check it out.
The weird thing is, each of our client's has "Options/Request exclusive lock" turned off. For instance, we very often have any given aspx or config file checked out to three developers?
Is this by design? Can we allow multiple check outs on project files?
Thanks.
//Stephen R.
Visual Studio Project file exclusive locking
Moderator: SourceGear
Stephen:
Vault will place an exclusive lock on any file, which it deems to be binary. Basically, any file not specifically assigned as mergeable ( text ), or which doesn't match an extension of known mergeable file extensions is deemed as binary.
My guess is you need to use the Admin Tool to add *.csproj to the list of mergeable files. This will enable multiple checkouts on the file.
Vault will place an exclusive lock on any file, which it deems to be binary. Basically, any file not specifically assigned as mergeable ( text ), or which doesn't match an extension of known mergeable file extensions is deemed as binary.
My guess is you need to use the Admin Tool to add *.csproj to the list of mergeable files. This will enable multiple checkouts on the file.
Jeff Clausius
SourceGear
SourceGear
Thank you for the reply. I have the admin tool open and I see what you are talking about. Maybe you could help me understand it a little better. I understand what you said, that to have multiple checkout on the .csproj i would add the extention to the Mergable list.
But why would csproj be under File Exclusions by default? When adding projects to Vault, it also adds my project file by default? Isn't that right?
Thanks so much.
//Stephen
But why would csproj be under File Exclusions by default? When adding projects to Vault, it also adds my project file by default? Isn't that right?
Thanks so much.
//Stephen
-
andyandy
btw: example text incorrect
BTW, when you fix this,
you might want to fix the example label text on
Repository Options tab -> File Types panel -> File Exclusions...
The example text has ( ex. *.csproj; *.dll; )
which as you have mentioned, is not true.
And ironically, its not in the list of default File Exclusions anyway.
As you mentioned, it should be in the list of Mergeble Files by default.
you might want to fix the example label text on
Repository Options tab -> File Types panel -> File Exclusions...
The example text has ( ex. *.csproj; *.dll; )
which as you have mentioned, is not true.
And ironically, its not in the list of default File Exclusions anyway.
As you mentioned, it should be in the list of Mergeble Files by default.
Good catch - we just updated that label in 3.0.3, so it should be correct now...
We still have not decided to put .csproj in the mergable file list by default. Although it is a text file, it is generated by Visual Studio, and when two people change it at the same time, VS will sometimes make wildly different changes to the file, which makes it really hard to programmatically merge changes.
What we need is a special merge tool that handles .sln and .csproj files, and knows what exactly it is looking at, so it can recognize the content of a change (say a file addition in one version and a file deletion in another version), and ignore any of the textual formatting of the changes that VS might make. But, we don't have that yet, so we have chosen to require the user to add the file to the mergable list if they want to trust project file merges.
We still have not decided to put .csproj in the mergable file list by default. Although it is a text file, it is generated by Visual Studio, and when two people change it at the same time, VS will sometimes make wildly different changes to the file, which makes it really hard to programmatically merge changes.
What we need is a special merge tool that handles .sln and .csproj files, and knows what exactly it is looking at, so it can recognize the content of a change (say a file addition in one version and a file deletion in another version), and ignore any of the textual formatting of the changes that VS might make. But, we don't have that yet, so we have chosen to require the user to add the file to the mergable list if they want to trust project file merges.