LABEL a label

[Eric Willeke]

I'm not the original poster of this thread, but I asked the question a few weeks ago.

We have dire need of label style two in order to support our style of FDD.
Use case:
All of our (six) developers work in the same common code base. As features get reviewed, the specific reviewed version of the files get marked with the [Approved] label, which was initially applied before we imported any contents and has been progressively promoted to the appropriate versions as work is performed. (This all works fine)

Our build server (CC.NET + nAnt) has two primary builds configured. The first is our ongoing development build, which detects changes, waits for quiet, then builds. Upon successfully building, it then applies a new label to the entire file set as a record of what was in the build. (This also works)

The second primary build is of our approved product. This consists of building everything that has the label [Approved]. We get all of the files with that label, then build them. If successful, we'd like to then apply a label to this set of files (which in effect, is making a copy of the [Approved] label). This is the step we can't do with the available Vault functionality.

I've been planning on writing a script to perform this action; however, I'd be quite appreciative if anybody has any suggestions of ways to modify the mechanics of this process without changing the effects (two tracked builds, one with explicitly approved contents.)

[dan]

Thanks for the clarification on the process. I can see why labeling a label would be useful when the folder label is continually promoted to new versions.

Another way to do this (not necessarily a superior way, but a different way) that Vault supports is to have two branches, one mainline, and one development. As files get approved in the development branch, you can use Merge Branches to move the approved changes over to the mainline development branch. Then, your stable builds happen in the mainline, and your test builds happen in the development branch.

Nonetheless, I'll update the feature request to reflect how labeling a label would work. Thanks.

[christian]

Dan,
In order to stop your customers from reinventing new and ingenious ways of supporting parallel development / release management it would be really useful for the Vault help files to recommend a number of "best practice" approaches and a step-by-step guide how to implement these in Vault. Obviously there won't be one solution that fits all so each recommendation should mention the forces in play and trade-offs for each approach.
Christian

[dan]

Yes, that is in the works. Eric is in the process of writing up standard practices at http://www.ericsink.com/scm/source_control.html. We will of course turn these into actual documentation as they get finished. Thanks for your patience, in the meantime

[Guest]

Is it that difficult to implement LABEL a LABEL in Vault? We are waiting for long time to get this feature and I think it is time to move to another Source Control system. Vault really doesn't support code promotions like the one in PVCS.

[mlippert]

Not that Eric doesn't have enough to do, but having just read this thread for the 1st time, I'd like to push for Christian's suggestion of a best practices documentation along with a step by step how to implement them using Vault.

It would definitely help as I see people asking these types of questions here all the time.

Obviously there are lots of "best practices" and different ways to implement them with varying trade-offs, so it will have to be a work in progress, but I think the "parallel development / release management" best practice would be a great place to start.

Mike

[ericsink]

Not that Eric doesn't have enough to do, but having just read this thread for the 1st time, I'd like to push for Christian's suggestion of a best practices documentation along with a step by step how to implement them using Vault.

It would definitely help as I see people asking these types of questions here all the time.

Obviously there are lots of "best practices" and different ways to implement them with varying trade-offs, so it will have to be a work in progress, but I think the "parallel development / release management" best practice would be a great place to start.

Mike

I'm interesting in knowing specifically how my Source Control HOWTO falls short of what you want. Is it the "step by step how to implement them using Vault" part?

[mlippert]

Eric,
I did a bad thing, I didn't check on the status of your howto, and I'm a chapter behind. I'll read the latest chapter and post again, my comments prior to getting up to date follow.

But yes, I was thinking that step by step using Vault is very important in what I was talking about above. And although I think what I've read so far was great, it was still coving the basics and not the "OK I know what the tool does, what problems can I use it to solve and how do I do that?" question, which is more of what I think of as best practices.

As a start, how does SourceGear lay out the Vault project? What are your policies, what issues do those policies address?

policies like:
what is labeled, when and who applies the labels?
Is label promotion ever used?
How about file or folder sharing?
When do you create branches and what are they for (release, disruptive development...)?
When do you merge branches? Which direction (original to branch or branch to original)?
Who does the merge (the developer, the release engineer, a team)?
How do you keep track of what was merged (label, comment...), so you can go back later and trace the history?
How do you manage 3rd party tools that are components of your project? How about if you also have the code and build those tools?

I'm sure there are other questions that just aren't occuring to me right now.

So these are all questions that I think could 1st be answered in terms of the goals you have at SourceGear. I know there are other approaches that you may not understand as well since you don't use them. Howver, the next step would be to get a few other scenarios documented (also with how to implement in Vault) hopefully with help from Vault users who are implementing those scenarios.

Mike

[tschroedter]

Hi,

can anyone tell me the current status of label a label? - I'm looking for a feature to identify a file version by a label and apply a new label to this version.

Tom

[lbauer]

It's on the list of features under consideration for Vault 4.0. I'll add your "vote."

[robe070]

We are using Vault 5.0.3. We cannot find a way to copy a label. Is this truly still not in Vault after all these years?

The alternative suggested is branching and merging back.

Branching is messy because its not a linked branch. It becomes a completely separate development stream - separate history, etc. It also does not link back to the parent structure. So a 3-way merge is not possible. And the merge tool is cumbersome as described in another thread thats been alive recently, so merging back changes to the main structure is a pain.

For small source tree structures, labelling and moving labels to identify what finally gets released is a practical alternative to branching. But if the released code identified by the label then needs to be modified for another release. You're stuck. Its been released so the label must not be moved. You can't copy the label - no feature. You can't branch it - changes have been made. You're stuffed! Only way out is to label/branch the original Version and then move labels or merge changes across.

Really, labels are impractical for use in release identification. Once a label is moved, it severely limits functionality.

Its essential that Copy Label to another Label and branch a label thats been changed are added to Vault. Without this, Vault has warts you need to workaround in order to control a professional software product. We are very disappointed with both Vault and our ability to review a product for our use. Vault has failed us and we have failed ourselves.

[jclausius]

Rob,

You make some good, strong points in your post. I don't know what is involved with implementation of copy a label, but I'll add this to the list of things to discuss once we're ready to sit down and discuss new features. We're still putting out some fires with VS 2010, and your patience is appreciated.

[robe070]

Jeff,

This thread has been going a long time - 6 years I think. So VS 2010 issues are not whats in the way of providing this feature. It just hasn't been considered important enough. And its only a part of what I consider the missing features in Vault to make it a top class industrial strength VCS. And most of the rest is about branching and syncing back to the main development stream. Its about connecting branches into a tree and understanding whats already been merged and using that when merging in further changes. I call this Merge Points and Sync Points, requiring a 3-way diff. Maybe those are terms that mean something to you. It just isn't there. We purchased Vault on the understanding these features were in the product, but our analysis of the available features was incorrect.

We will not be ditching Vault in the medium term. Its just too expensive to switch everybody and everything to another VCS. And its basic functionality is very robust. And we can workaround the issues or just take more time to perform tasks or just not do things like parrallel versions for implementing new functionality.

regards

Rob Goodridge

[jclausius]

Rob,

In the grand scheme of things, no VS 2010 has not been what is in the way. Not implementing this was based on internal decisions by who or what was driving the feature set for that particular version of Vault/Fortress. However, at this point in time, I am in the driver's seat, and I do think what you, GregM, lynnroth, and others have to say is important. But, I also want to understand what is driving a feature request, see if the request has value to Vault/Fortress customers as a whole, and weigh the opportunity cost of implementing a particular feature over another.

Addressing the Label Copy feature, I've gone through this thread and other similar requests, and I understand how this feature would be beneficial in a dev environment where a "perpetual label" which is constantly being promoted is used, and the Label Copy is used to take a "snap shot" of that label. I will get in for a closer look in the near future, but for right now there are more pressing issues. This is not lip service, but things will not happen overnight, and I wanted to make sure you know where things stand.

[robe070]

Jeff,

Thanks for the candid response. As a software developer I totally understand the process of managing software change.

To get a little clearer on our need for Copy Label... Its not so much a perpetual label, though thats a view that fits how we use it to some extent - the labels are required to exist for as long as we support a version. But, the crux for us is that once we release a version, its the label that identifies it. It can't be a Version because we have moved the label on some of the files. We then copy that label in order to work on any further fixes. The original label will NOT be changed. It tells us exactly what was released. We must not change it at all. Once we have Copy Label, a minor nice-to-have would be the ability to lock the original label so that it can't be changed.