How to add the changes in a changeset to an existing label?

robe070 · Post by **robe070** » Mon Jun 30, 2008 6:49 pm

We have applied a label to a version. We have promoted the label on some files. We have continued development for the next version of our software. We have found a critical error just before shipping that we need to include in the release build (i.e. label). This change will be in the next version so there is a changeset in this branch with the changes we want to include.

How can I just ask Vault to apply the label to the versions of the files in the changeset? I could do this through promotion, but that could be tedious with many files in disparate folders and prone to error - choosing an incorrect version or even an incorrect file.

Secondly, a NEW file has been added in the changeset. this CANNOT be promoted because its not labeled at all. How do I add this to the label?

A branch is a possible solution (branch at the label and merge the changes to the tip and label the tip) but seems overkill when we have 10,000+ files in our software and want to adjust the label on only 3 files.

Beth · Post by **Beth** » Tue Jul 01, 2008 2:18 pm

Label promotion is the way to go here. You will change it to use the appropriate versions, and you can add a file to it as well.

robe070 · Post by **robe070** » Tue Jul 01, 2008 7:55 pm

Hi Beth,

I'm asking for an improved method of promoting changes to a label. Vault uses Changesets so why not allow a Changeset to be chosen and the label 'promoted' to the version of teh files in the Changeset?

If this was available it would be quicker and eliminate mis-labelling.

Beth · Post by **Beth** » Thu Jul 03, 2008 1:44 pm

What if you deleted the label, and just set it again at the version you want it at?

andrews · Post by **andrews** » Thu Jul 03, 2008 4:48 pm

A problem with that - imagine after creating a label, 3 changesets were added. Then consider that only the contents of the 3rd changeset were to be included in the label (assume the 3 changesets affected different files).

Deleting (or renaming) and creating the label anew would include the other 2 changesets. The only alternative at the moment is to use promotion to update the file versions in the label, file by file. If that 3rd changeset affected, say, 20 files in different directories, the task of promoting them is difficult and prone to user error. If instead the user could see a list of changesets added since the label and click on one, that'd be much easier.

robe070 · Post by **robe070** » Thu Jul 03, 2008 9:00 pm

What Andrew says is basically my situation too. There is not one particular folder version that is the one we need to label. I tried to paint a picture in my first post of a place in the development life cycle where this is likely to occur, and in fact has occurred for us. Its near release of a version. We do not want to add risky changes to the product as we must release it very soon. So, a few important but low risk changes get applied, but the rest need more testing and will be in a bug release that will follow up the main relaease ASAP.

The changes are not being done sequentially. That is we can't have developers setting around twiddling their thumbs. All fixes that are required whether in the 1st release or the bug release are being worked on at the same time. Thus the changesets are out of order for labelling a particular changeset because it includes changes we do not want in yet.

lbauer · Post by **lbauer** » Mon Jul 21, 2008 10:26 am

There may be ways to do this with the client API, but it's probably not easy.

We're looking at ways to make it easier for developers to get or label items that are not neatly in a specific change, such as files that have changed since a specific date, files that have changed between two labels, and other situations like that. I'm not sure when this might be implemented however.