Hi
I hope you can help me with this one, because I have not been able to figure it out myself:
I used SourceSafe earlier, and would like to acomplish some of the same functionality in Valut. In SS I had this kind of project-hieraky:
. Development
. . MyApplication
. . MyDLL
. . MyDll2
. Production
. . Version 1.1.1.1
. . . MyApplication
. . . MyDLL
. . . MyDll2
. . Version 1.1.1.2
. . . MyApplication
. . . MyDLL
. . . MyDll2
. . Version 1.1.1.3
. . . MyApplication
. . . MyDLL
. . . MyDll2
. . . . . . . And so on . . . . .
All development was done under the project Development.
When the first testversion was ready [Development] was shared (via show history) to a new project called [Version 1.1.1.1]. This would cause alle files in the new share to be pinned at the newest vesion.
Later version 1.1.1.2 was to be released but some files was not ready/ment to be released yet, so we then shared [Version 1.1.1.1] to [Version 1.1.1.2].
We now had two identical projects.
Files ready for the new version were pinned to a newer version so the result would be a version similar to version 1.1.1.1 plus the selected new file versions.
We would then "Get" the new version and build the release files from this code.
This way it was later very simple to see the differences between MyApplication in version 1.1.1.1 and version 1.1.1.2. Or between 1.1.1.1 and Development\Myapplication.
And all released version vere kept track of in this way.
The abowe hieracy is an example. This layout is perhaps more describing:
. Development
. . MyApplication
. . MyDLL
. . MyDll2
. Production
. . MyApplication 1.1.1.1
. . MyApplication 1.1.1.2
. . MyApplication 1.1.1.3
. . MyDLL 1.1.1.1
. . MyDLL 1.1.1.2
. . MyDLL 1.1.1.3
. . MyDll2 1.1.1.1
. . MyDll2 1.1.1.2
. . MyDll2 1.1.1.3
. . . . . . And so on . . . . .
(MyApplication 1.1.1.3 is a pinned share of MyApplication 1.1.1.2 whis i a pinned share of MyApplication 1.1.1.1 which is a share of Development\MyApplication)
We never used labels.
So how do I acomplish something similar in Vault. As I see it pinning is not usefull, since it differs alot from pinning in SS. In Vault pinning is shared between folder/project shares, and it is not possible to pin a file, that is checked out. Nor is it possible check out a file, that is pinned. This makes pins unusable. Or am I mistaken. What is the practical purpose of pinning in Vault.
We are 7 developers using Vault. We use it with Delphi2006 and SourceConneXion.
I hope you can get me some input.
PS: We are currently on version 3.1. Do you know if there is any compatibility-issues to SourceConneXion if we upgrade to version 3.5?
TIA
Ejnar Dahl Jensen
Simplex A/S
How to keep track of all production versions
Moderator: SourceGear
Pins were intended to stop development at that point on a file.
If you ever need to pull changes from one of your files or folders that you are currently sharing, then I'd suggest branching. The changes in branches aren't automatically shared, but you have the option of merging branches if you have one that has changes that another needs.
After version 3.5, users have another version of using our import/export tool to make a copy that has the full history with it and placing it in another location. That is recommended if you never have to merge data between the two.
We have a few KB articles of best practices that you might want to check out.
Best Practices for Managing Branches
Basics of using Label, Cloak, Share, Pin, Branch and Merging
Or you can check out Eric Sink's Source Control How To
We haven't tested with SourceConneXion. You can download our latest version to try it out first if you wish. You will want to take a look at our release notes for Vault 3.5.0 and Vault 3.5.1.
If you ever need to pull changes from one of your files or folders that you are currently sharing, then I'd suggest branching. The changes in branches aren't automatically shared, but you have the option of merging branches if you have one that has changes that another needs.
After version 3.5, users have another version of using our import/export tool to make a copy that has the full history with it and placing it in another location. That is recommended if you never have to merge data between the two.
We have a few KB articles of best practices that you might want to check out.
Best Practices for Managing Branches
Basics of using Label, Cloak, Share, Pin, Branch and Merging
Or you can check out Eric Sink's Source Control How To
We haven't tested with SourceConneXion. You can download our latest version to try it out first if you wish. You will want to take a look at our release notes for Vault 3.5.0 and Vault 3.5.1.