We're considering upgrading from Vault 3.5.2 to Vault 4.0.1. Is this advisable? One concern raised is whether new 4.0 features make the risks associated with a new major release worthwhile.
We've had a lot of difficulty binding all the projects in a complex Visual Studio 2005 solution using the Vault client. Has this process been improved significantly in the 4.0 VS 2005 client?
Does 4.0 VS 2005 client improve binding projects to Vault?
Moderator: SourceGear
In short: not yet.
The 2005 client no longer uses MSSCCI-style binding at all. 4.0 shipped with binding options to support the most common scenarios, but if you have fairly complex binding requirements it's probably not going to meet your needs yet.
Improving the binding experience is a high priority for a 4.0.x release, and in fact I'd welcome your input into how we could make your life easier. If you'd prefer to not do so publicly, you can email me via the button below.
The 2005 client no longer uses MSSCCI-style binding at all. 4.0 shipped with binding options to support the most common scenarios, but if you have fairly complex binding requirements it's probably not going to meet your needs yet.
Improving the binding experience is a high priority for a 4.0.x release, and in fact I'd welcome your input into how we could make your life easier. If you'd prefer to not do so publicly, you can email me via the button below.
Ian Olsen
SourceGear
SourceGear
Problems binding projects in a VS 2005 solution
We don't have any experience with v4.0 yet, so this is all based on VS 2005 and Vault 3.5.2.
We frequently see a Source Control dialog:
A project or solution you are trying to bind contains items that are in the same folders as projects that are currently under source control. To resolve this issue, you will need to move these items into their own folders or bind each overlapping project separately.
It is true that we have files that are shared between projects. These are typically header files, but occasionally .cpp files.
Sometimes the Add to Vault Folder dialog gets messed up, meaning the name of the branch will show up multiple places in the Add project to Vault folder. Since we can't edit it directly, it is difficult to work around. In fact our main workaround right at the moment is to text edit the .sln file.
Another issue is that the .vcproj files don't always use SAK. We have to fix those by hand sometimes.
CanCheckoutShared = false when it should be true. We have to fix that by hand.
It is inconvenient to keep binding information in the source files themselves because when we branch, the bindings are then wrong. Since rebinding in Visual Studio using Change Source Control almost always fails, this can lead to endless struggles. All we want to do is say that everything underneath some branch-level project folder is bound to the corresponding branch in Vault. Ideally that would be in a single place.
We might want to override the binding in the same way an inherited working folder may be overriden. Some developers have expressed interest in working in CVS mode. Your release notes say that is supported.
How can I learn about how the 4.0 VS client integration works in this regard?
We frequently see a Source Control dialog:
A project or solution you are trying to bind contains items that are in the same folders as projects that are currently under source control. To resolve this issue, you will need to move these items into their own folders or bind each overlapping project separately.
It is true that we have files that are shared between projects. These are typically header files, but occasionally .cpp files.
Sometimes the Add to Vault Folder dialog gets messed up, meaning the name of the branch will show up multiple places in the Add project to Vault folder. Since we can't edit it directly, it is difficult to work around. In fact our main workaround right at the moment is to text edit the .sln file.
Another issue is that the .vcproj files don't always use SAK. We have to fix those by hand sometimes.
CanCheckoutShared = false when it should be true. We have to fix that by hand.
It is inconvenient to keep binding information in the source files themselves because when we branch, the bindings are then wrong. Since rebinding in Visual Studio using Change Source Control almost always fails, this can lead to endless struggles. All we want to do is say that everything underneath some branch-level project folder is bound to the corresponding branch in Vault. Ideally that would be in a single place.
We might want to override the binding in the same way an inherited working folder may be overriden. Some developers have expressed interest in working in CVS mode. Your release notes say that is supported.
How can I learn about how the 4.0 VS client integration works in this regard?
How does binding in the VS 2005 client work?
Ian Olsen wrote:
"The 2005 client no longer uses MSSCCI-style binding at all."
Could you explain how binding in Vault 4.0/VS 2005 client works? Or point me to some documentation about it? I'm particularly interested in any changes in the behavior of the VS 2005 Change Source Control function and in what files the bindings are kept. What source control files does VS want to keep in source control?
"The 2005 client no longer uses MSSCCI-style binding at all."
Could you explain how binding in Vault 4.0/VS 2005 client works? Or point me to some documentation about it? I'm particularly interested in any changes in the behavior of the VS 2005 Change Source Control function and in what files the bindings are kept. What source control files does VS want to keep in source control?
We don't have any detailed documentation about binding changes, so let me describe the changes:
1) Binding information is in the solution/project files themselves. There are no vspscc or similar files.
2) Other than getting rid of the vspscc-like files, there is no change in behavior as far as what files are put in source control.
3) There is no repository path information stored in projects. Repository path is determined only by working folder assignments.
4) Solution files contain only relative repository paths. This means that in your scenario after a branch, as long as all source-controlled projects referenced by the solution file are included in the branch, you shouldn't have trouble just opening the newly branched solution.
5) We've gone to great lengths to be smarter about what working folder assignments we make based on the relative disk paths for a solution.
There were two oversights related to binding that we made in the initial release that we're now working on, to be included in a 4.0.x release:
1) We made bind/unbind an all-or-nothing operation for the currently open solution. You can't bind/unbind individual projects, which simply doesn't match the way people work, frequently. We're fixing that, adding an interface similar to what the MSSCCI client has.
2) Some people need to have "local overrides" for connection information: info stored on a workstation outside the project/solution file. For example, you may access your Vault server via http://vaultserver in the office, but https://10.1.30.4 from home. We're adding local-only connection settings that don't get added to the repository. This data will be located in Vault's application data folder, not in the project/solution working folder.
Hopefully that's helpful. By all means let me know if there are other questions I can answer, either here or email me using the button below.
1) Binding information is in the solution/project files themselves. There are no vspscc or similar files.
2) Other than getting rid of the vspscc-like files, there is no change in behavior as far as what files are put in source control.
3) There is no repository path information stored in projects. Repository path is determined only by working folder assignments.
4) Solution files contain only relative repository paths. This means that in your scenario after a branch, as long as all source-controlled projects referenced by the solution file are included in the branch, you shouldn't have trouble just opening the newly branched solution.
5) We've gone to great lengths to be smarter about what working folder assignments we make based on the relative disk paths for a solution.
There were two oversights related to binding that we made in the initial release that we're now working on, to be included in a 4.0.x release:
1) We made bind/unbind an all-or-nothing operation for the currently open solution. You can't bind/unbind individual projects, which simply doesn't match the way people work, frequently. We're fixing that, adding an interface similar to what the MSSCCI client has.
2) Some people need to have "local overrides" for connection information: info stored on a workstation outside the project/solution file. For example, you may access your Vault server via http://vaultserver in the office, but https://10.1.30.4 from home. We're adding local-only connection settings that don't get added to the repository. This data will be located in Vault's application data folder, not in the project/solution working folder.
Hopefully that's helpful. By all means let me know if there are other questions I can answer, either here or email me using the button below.
Ian Olsen
SourceGear
SourceGear
Vault 4.0/VB binding process is very close to what we need.
Thanks for your detailed reply. I think you've addressed 90% of what I needed to know and it sounds like Vault 4.0.1 is very close to the process we need.
Getting rid of the vspscc-like files is a plus for us. Keeping the repository path out of the projects will make branching easier, and also make it possible to change the working folder without having to rebind everything (it sounds like). I see how relative paths are important in making that work.
1) Currently we spend a lot of time getting all of the projects in our solution bound. All-or-nothing is exactly how we work and achieving that using Visual Studio's interface was problematic. This sounds like a major improvement for us.
2) We don't expose our Vault server to the internet; it is always accessed via VPN, so we don't have any need for local connection overrides. The only place I see connection information is in the MSSCCPRJ.SCC files. Do you still use those? We don't keep these under source control, so what project file(s) are you referring to that need to be overridden?
One thing I didn't mention is that we have a $/Experimental branch which is a place we develop new projects until we're ready to add them to the build. The working folder for $/Experimental/x will be set to \branch\...\x, adding to the body of projects in the branch. I don't think we use VS binding for this, although can't tell if you've improved it either.
Getting rid of the vspscc-like files is a plus for us. Keeping the repository path out of the projects will make branching easier, and also make it possible to change the working folder without having to rebind everything (it sounds like). I see how relative paths are important in making that work.
1) Currently we spend a lot of time getting all of the projects in our solution bound. All-or-nothing is exactly how we work and achieving that using Visual Studio's interface was problematic. This sounds like a major improvement for us.
2) We don't expose our Vault server to the internet; it is always accessed via VPN, so we don't have any need for local connection overrides. The only place I see connection information is in the MSSCCPRJ.SCC files. Do you still use those? We don't keep these under source control, so what project file(s) are you referring to that need to be overridden?
One thing I didn't mention is that we have a $/Experimental branch which is a place we develop new projects until we're ready to add them to the build. The working folder for $/Experimental/x will be set to \branch\...\x, adding to the body of projects in the branch. I don't think we use VS binding for this, although can't tell if you've improved it either.
We're not using any external SCC-specific files, so the MSSCCPRJ.SCC files are also gone. The relevant data is within the project file itself (e.g. .csproj) except for web site projects (not to be confused with web application project), because they don't have a project file.
You may still experience some difficulty with the experimental projects that aren't beneath your solution in the repository, but it should be manageable.
There's one thing I can suggest, if you want to try things out without jumping in with both feet. As before, you can run Vault 4.0 as a single user at no cost. You can install both client and server on a test machine somewhere, export some projects from your 3.5 server, import them on the 4.0 server, and try things out.
You may still experience some difficulty with the experimental projects that aren't beneath your solution in the repository, but it should be manageable.
There's one thing I can suggest, if you want to try things out without jumping in with both feet. As before, you can run Vault 4.0 as a single user at no cost. You can install both client and server on a test machine somewhere, export some projects from your 3.5 server, import them on the 4.0 server, and try things out.
Ian Olsen
SourceGear
SourceGear
Does Vault 4.0 use scc files for web site projects?
All of our web projects are web site projects. Does that mean Vault 4.0 keeps binding information in scc files for these and works the same as in 3.5?