We are using Vault v3.5.1 and I have some general questions regarding the preferred/ideal way to use Vault for our given scenario. We have many clients that use our suite of products. Not all of these clients are on the same version, however newer releases are cummulative and backwards compatible. We have maintenance releases that will need to be either labeled or branched. To add to this we also have situations where a client will need an emergency fix. We want to be able to accomodate this need smoothly by creating a new branch or label where our QA team will test these emergency fixes while our maintenance dev team continues with their normal development. At this point we would have at least two different versions of the code. We would eventually want to merge this back into our main code base but in the meantime we may have gone through one or more maintenance releases.
What is the best way to handle this issue? Labeling or Branches......
Looking forward to your responses.
-Brian Evans
Vault recommendation - branch or label?
Moderator: SourceGear
I think it would be less confusing to use branches when you are making maintenance releases for customer. Then you wouldn't have to worry about development that has moved forward ending up in the maintenance release. I would also say to use labels liberally as well just to mark builds and releases.
For example:
Trunk --- Forward development onto v4 of your product.
|
--Branch---this branch was created at version 3.0. The maintenance releases of 3.1, 3.2, 3.3 and so on will go here and be merged back to the Trunk so that v4 gets all the same changes. So that you know what was released, label version 3.1, 3.2, and 3.3 and so on. Since these are maintenance releases, most likely one wouldn't be working on 3.3 at the same time as 3.1. These are linear.
For example:
Trunk --- Forward development onto v4 of your product.
|
--Branch---this branch was created at version 3.0. The maintenance releases of 3.1, 3.2, 3.3 and so on will go here and be merged back to the Trunk so that v4 gets all the same changes. So that you know what was released, label version 3.1, 3.2, and 3.3 and so on. Since these are maintenance releases, most likely one wouldn't be working on 3.3 at the same time as 3.1. These are linear.
-
brianhevans
- Posts: 2
- Joined: Tue Dec 18, 2007 9:34 am
So when using Labels a particular version can be assigned a label and then new development can continue on the original code base and once that is complete a new label can be created and we would have two different labeled versions of the code? Would the later labeled version contain all the code in the first labeled version and so on?
Yes. Labels are good for linear development where you are just going in a straight line from one to the other and not stepping back. If you step back, then it's very easy to get confused on what changes are where. That's why I recommend branching for things that are going to get fixes, and since fixes are mostly linear, labels tend to be good for those.
You can also label right before you branch or any kind of event you'd like. A label just shows the state of that folder(s) and/or file(s) at the point that label was applied. It's almost like a bookmark in a way.
If needed, you can make changes to labels through Label Promotion, but I usually don't recommend that as a regular way of managing development. I think it works better for fixing a mistake or one-time oversight.
You may find some of our KB articles help explain as well:
You can also label right before you branch or any kind of event you'd like. A label just shows the state of that folder(s) and/or file(s) at the point that label was applied. It's almost like a bookmark in a way.
If needed, you can make changes to labels through Label Promotion, but I usually don't recommend that as a regular way of managing development. I think it works better for fixing a mistake or one-time oversight.
You may find some of our KB articles help explain as well: