If someone would please point me to the article that covers the following topic I would appreciate it.
1) Work on version 1.0 of my product (Vault works great and I love it).
2) Release version 1.0 of my product (some customers love it, some want to go to step 4). Create Label in Vault at the root of my 2 repositories stating that it is version 1.0 (no problem).
3) Work on version 2.0 of my product, which I don't want to mingle with the version 1.0 code.
4) Customers with version 1.0 start to report bugs (I ask them to wait for version 2.0. I get a call from their attorney).
The question. How do I handle getting files out of Vault (from the Labeled version) and check those files back in to the labeled version?
It seems whenever I use the Vault client to get code out of the repository, I get a message in VS.NET about binding info cannot be found. MSSCCPRG.SCC file has been deleted.
TIA.
Scot Curry
Hotfix / Continuing Development
Moderator: SourceGear
-
CraigNicholson
- Posts: 47
- Joined: Tue Mar 23, 2004 3:54 pm
- Location: South Africa
- Contact:
This is actually something we've never really had to do with our software releases as we always try to ensure our customers are on the latest release of a product and each major version is a new source tree.
The feature I think you are needing to look at is the Snapshot feature. From what I can tell if you have version 1.0 in the tree as say $/myproduct/1.0/ you'd then snapshot to $/myproduct/2.0/ which would effectively do a share and branch operation to make $/mproduct/2.0/ as a share of $/myproduct/1.0/ and then it would pin $/myproduct/1.0/.
Can anyone tell me if my understanding is correct?
The feature I think you are needing to look at is the Snapshot feature. From what I can tell if you have version 1.0 in the tree as say $/myproduct/1.0/ you'd then snapshot to $/myproduct/2.0/ which would effectively do a share and branch operation to make $/mproduct/2.0/ as a share of $/myproduct/1.0/ and then it would pin $/myproduct/1.0/.
Can anyone tell me if my understanding is correct?
Craig:
Not exactly.
Here is a quick overview of snapshot.
1) Snapshot looks at a "picture" of the data at the version specified.
2) It then creates a lightweight copy based on that picture.
3) It places the copy into another location of the tree.
4) Finally the server pins the folder, so no-one can make a change without lifting the pin.
Not exactly.
Here is a quick overview of snapshot.
1) Snapshot looks at a "picture" of the data at the version specified.
2) It then creates a lightweight copy based on that picture.
3) It places the copy into another location of the tree.
4) Finally the server pins the folder, so no-one can make a change without lifting the pin.
Jeff Clausius
SourceGear
SourceGear
Scot,
In order to change the label, you will need to branch it. In the Show Labels dialog, you can select the label, right click and choose branch. Select the location where the branch should go (don't just put it under your src tree). You can then make changes in that branch, and merge those changes back into the trunk.
In the future, it's best not to label the $/ node of a repository, but to structure your repository like this:
$/trunk -- The main development tree
$/labels -- The tree that holds the 1.0, 1.0.1, 1.0.2 trees
$/branches -- The tree that holds experimental branches that might be abandonned completely
So your source would live in $/trunk/src, and your specs in $/trunk/specs, etc. Whey you hit version 2.0, you label $/trunk Version 2.0, and once you're gold (you can use label promotion to fix your label until you go gold), branch that label to $/labels/2.0. You can then work on $/labels/2.0 as its own tree, labeling it at 2.0.1 and 2.0.2. You shouldn't need to branch any of your 2.0.x labels, as they take precedence over the 2.0 label.
In order to change the label, you will need to branch it. In the Show Labels dialog, you can select the label, right click and choose branch. Select the location where the branch should go (don't just put it under your src tree). You can then make changes in that branch, and merge those changes back into the trunk.
In the future, it's best not to label the $/ node of a repository, but to structure your repository like this:
$/trunk -- The main development tree
$/labels -- The tree that holds the 1.0, 1.0.1, 1.0.2 trees
$/branches -- The tree that holds experimental branches that might be abandonned completely
So your source would live in $/trunk/src, and your specs in $/trunk/specs, etc. Whey you hit version 2.0, you label $/trunk Version 2.0, and once you're gold (you can use label promotion to fix your label until you go gold), branch that label to $/labels/2.0. You can then work on $/labels/2.0 as its own tree, labeling it at 2.0.1 and 2.0.2. You shouldn't need to branch any of your 2.0.x labels, as they take precedence over the 2.0 label.