We migrated from VSS to Vault about four years ago and have been quite pleased. As we mature our internal processes, we are trying to improve the way we "version" our products.
Background
Our core product is an ASP.NET webforms application with a series of supporting libraries. Currently, we are using both the Vault GUI and the enhanced client in VS.NET 2010 (will be upgrading to 2012 in the near future).
Regarding the ASP.NET piece, it is comprised of a dozen or so Web Applications (i.e. their own .sln file, their own virtual directory, etc.). For the sake of argument, we will refer to the top level virtual directory as http://server/ourApp_v1/ and each application is subordinate to it: http://server/ourApp_v1/subApp_1/ and http://server/ourApp_v1/subApp_2/ etc.
There are about 20 libraries and each is a simple DLL with its own .sln file.
As for our current Vault structure, we have individual repositories per version -- we are on version 8 and thus have 8 repositories containing everything (web apps, libraries, sql scripts, etc.). Working folders are based on the version: c:\ourApp_v1\ and c:\ourApp_v2\ etc.
Current Workflow
When we prepare a new version, we clone the entire repository into a new repository and make changes as needed.
However, if we discover we need to make a fix to an older version, we end up making the change in the repository without a clean way to segregate that individual change from the "release" structure of that same version. Moreover, trying to "get" the original release version or individual patches is onerous. We have used labels in the past, but find their lack of "obviousness" discouraging (i.e. you have to look into the history of a file to discover the label).
What are we asking?
Having read chapter 11 of Mr. Sink's book (thank you for making it available online; I have directed most of our team to it for reference) over and over, we are convinced that we can achieve zen via share/branch/merge. The libraries and sql should prove quite straightforward. However, we are failing to deduce the best approach for the web applications.
Originally, we considered a structure in Vault ala:
Code: Select all
$ourApp/
|
|--trunk/ (working folder c:\ourApp\trunk\; virtual directory: http://server/ourApp_trunk/)
| |
| |-- libraries/
| | |
| | |-- dataHandler/
| | [:]
| |
| |-- webapps/
| | |
| | |--portal/
| [:] [:]
|
|--v8/ (branch from trunk; working folder c:\ourApp\v8\; virtual directory: http://server/ourApp_v8/)
| |
| |-- libraries/
| | |
| | |-- dataHandler/
| | [:]
| |
| |-- webapps/
| | |
| | |--portal/
| [:] [:]
|
|--v9/ (branch from trunk; working folder c:\ourApp\v9\; virtual directory: http://server/ourApp_v9/)
| |
| |-- libraries/
| | |
| | |-- dataHandler/
| | [:]
| |
| |-- webapps/
| | |
| | |--portal/
| [:] [:]
[:]
The greatest hurdle appears to be the inability to map the two projects to the same working folder. Every time we think we have a solution, we end up with two projects pointing to the same working folder (the version's initial-release branch and the version's point-release branch).
Please, any insight/suggestions are welcome. As you can imagine, we have spent many hours thinking about this and only finally found the humility to ask the organization truly adept at the practice.
Regards,
Eric