Pin and ongoing check-outs and changes

[StevenBlack]

First post....

Here's what I need and, if I'm not mistaken, I believe other revision control systems work this way.

I need "Pin" to not mean "Freeze". I need to continue incrementally evolving files that are pinned.

In my view a "Pin" should be the version returned by "Get Latest Version", and allow development and incremental check-ins post-pin.

IN OTHER WORDS: in Vault, how does one allow incremental check-ins without risk of wrecking the build for everyone else?

Not interested in branching here because we're not branching. I need "Pin" to mean the most recent known stable version.

See, I want developers checking-in their work on a regular basis, and I don't want broken builds.

How to get this with Vault?

Thanks!

[jclausius]

Vault's definition of a pinned file or folder is to lock a specific version of a file or folder at an exact parent folder in the repository. That's not to say other modifications on those objects cannot occur, as changes to shared items (with different parents) can still be modified, but the pinned items stay intact.

Vault's definition of "Pinned" files is similar in concept to Visual SourceSafe.

With that said, committing a file will apply changes from n to n+1. So if user "A" commits their changes, user B is going to need to absorb the changes in order to commit n+2. And it is entirely possible those changes will break the build for User B. Now, if User C commits making version n+3, and n+1 and n+2 changes are not merged because they break C's build, then those changes will be lost when committed because C removed them.

I'll describe a way to keep things isolated in a follow up post.

[jclausius]

Not interested in branching here because we're not branching. I need "Pin" to mean the most recent known stable version.

Branching is the exact operation one should use to control a situation like this. The sandboxes created for doing your work keep everything in a stable environment, isolating changes until you are ready to merge them into a different branch for use by others.

So as user "A" makes changes, those changes are kept in an isolate branch from users "B" and "C". Only when it is safe to make sure those changes can be applied to others would they be merged.

HTH

[StevenBlack]

Hi Jeff, thanks so much for the reply.

But branching, you see, requires a duplication of the whole project tree or, at minimum, introduces a layer of complexity that we want to absolutely avoid.

The goal is pretty simple and, im my experience, universal.
* When user A checks out a file, then users B and C are not going to create mergable changes. That's what "exclusive" use gives us.

* We want user A to be able to archive changes as often as user A sees fit. It's all about being able to develop safely coherently in an interrupt-driven environment.

* We want users B and C to be able to retrieve files to as often as they see fit, but the GET needs to be the latest stable version or, at least, a version developer A is happy with.

So I guess what you are really telling me is labels is the only way to do this. The problem with labels is you can have only one. A particular file cannot be, at the same time, "Version 9" and "Version 10 latest dev"

Seeing everything that's configurable in Vault, it's pretty staggering that "Pin" is so, to be honest, dumb.

[jclausius]

But branching, you see, requires a duplication of the whole project tree or, at minimum, introduces a layer of complexity that we want to absolutely avoid.

At what level? Within Vault itself, a branch is just a bunch of reference pointers back to the source of the branch, nothing is duplicated. At the Vault server level, the branching is very light weight.

The goal is pretty simple and, im my experience, universal.
* When user A checks out a file, then users B and C are not going to create mergable changes. That's what "exclusive" use gives us.

* We want user A to be able to archive changes as often as user A sees fit. It's all about being able to develop safely coherently in an interrupt-driven environment.

* We want users B and C to be able to retrieve files to as often as they see fit, but the GET needs to be the latest stable version or, at least, a version developer A is happy with.

But if users B and C will be modifying files, they will need the LATEST version of any file. Since a file modification will create the "next" version of the file, Vault will base this off the LATEST version, not a stable version that may be many versions out of date.

Here's an example:

• User A decides foo.cls should be at version 5 (stable) and bar.bas should be at version 3.
• User B does a GET on foo.cls "stable", and starts working based off of version 5.
• User A finds some typos, adds comments, and makes a quick code changes creating a dependency on a new function in foo.cls which also requires an changes to bar.bas. These changes create versions 6, 7, 8, and 9 of the foo.cls, and bar.bas is now at version 4.
• User B has made some changes to foo.cls, and now ready to commit those changes. If User B checks in the code as is, versions 6, 7, 8, & 9 will be lost. Fortunately, Vault will recognize this and will throw a "Needs Merge" error. At this time, user B will be prompted to merge in the changes of 6, 7, 8, and 9 of foo.cls or allow user B to over-write those changes.

Now imagine the change in bar.bas will break B's build. So user B is now at an impasse. User B needs to commit changes for foo.cls, and needs to GET the latest to do so. However, getting version 9 will require version 4 of bar.bas and this version will break B's build.

This is where a branch would come in. In the case of a branch, User B's files would still be stable with the contents of foo.cls at version 5 and bar.bas at version 3. No amount of changes made by User A in the other repository path will impact User B. When User B feels confident the changes are good, a merge can be made to place the changes of B into the main trunk. And if changes in the main trunk are required by B, a merge can be made in that direction as well.

So I guess what you are really telling me is labels is the only way to do this. The problem with labels is you can have only one. A particular file cannot be, at the same time, "Version 9" and "Version 10 latest dev"

?? Any single version of a file can have multiple labels. Version 27 of readme.txt may be labeled "release 1.0", "release 1.1.", "release 1.2", and so on and so forth. There is no restriction of versions of a file to multiple labels.

There should be a couple of ways to do this, but only branching or snapshots will allow users B and C to make changes to the same files User A is also modifying. Now, if Users B and C just need "read-only" copies of a library or a group of files you could use Label, Branch, Snapshot, or a Shared Folder with Pins.

HTH

[StevenBlack]

Hi Jeff, let me explain again, because I don't get the sense that you are listening.

1) Developer A CHECKS-OUT file Foo. It's his exclusively. He'll be working on it, maybe for a while. Say several days.

2) Developers B and C are working on other dependent aspects of the application.

So you are telling me: With Vault, developer A is *completely* out of luck. He can't check-in file FOO at any point because he may break functionality required by B and C. Boss D. supervisor of A, is also out of luck and there is no way that Boss D can view anything being done by developer A because A is not checking-in files for mortal fear of busting-up everyone's environments.

You then are also telling me that Developer A should create a branch, even though he is not branching, just incrementally improving, and to do so he needs to go through gyrations with different local folders because Vault can't map multiple project folders to the same physical folder at all

So question, then: How the heck is developer A supposed to be using Vault? Is he supposed to use ANOTHER revision control system to save his incremental but not-ready-for-prime-time work? If I understand you correctly, we are to "pretend" to be branching, even though we are doing no such thing, and Developer A must muck-up his physical folders, introducing new folders to hold the branched file, scoping that new folder prior to the real folder containing the original file Foo?

Vault seems to me, at least on first impression, to be a massive concession to ease of development for YOU GUYS as opposed to being able to address this very simple and common scenario, which is: developers regularly checking-in files without risk of breaking the application for everyone else.

If I'm incorrect, as I suspect I may be, can you please explain to me how developer A is supposed to work with Vault? Please don't invent problems, like Developers B and C also working on file Foo. They are doing no such thing.

We just need Developer A to be saving his work regularly so we can
* keep an eye on progress (using Diff) and
* not break the build, all the while
* providing a safety net for Developer A to make extensive and revisionable changes to files.

The problem here may be (correct me if I'm wrong) is the assumption that all developers need to be working with the very latest versions of all files, even those that have not passed basic QA. With Vault, you assume QA, and remedies, precedes ALL checkins. Is this correct?

In Vault, it appears that "Pin" means "Freeze". We need to be able to create software without a veritable explosion of projects or kluging non-branches as branches in our repository. We have a real clear picture of what files are workable, and what files are volatile. What I think you may be saying: get used to branching because this is the only way Vault can work.

[jclausius]

Steven:

Steven, I agree. We're not on the same wavelength here. I'll address your last post in a follow up, but first, let me ask a question.

I thought I saw you mention use of Visual SourceSafe. Is that correct? Were you using VSS' pins as well? Vault's pins work exactly like VSS - if a file is pinned it cannot be modified, and the version is locked until the pin is lifted. If that is the case, then there should be no change in how you were originally doing things.

The branch assumption made in previous posts were about isolating development paths to allow concurrent development in different parts of the repository. A nice description of this development style can be found at http://www.ericsink.com/scm/scm_branches.html

[GregM]

Sounds like Steven is looking for shelving (which was not provided by VSS, but is by TFS):

http://support.sourcegear.com/viewtopic.php?t=3494

[jclausius]

Sounds like Steven is looking for shelving (which was not provided by VSS, but is by TFS):

I'm not certain. Regardless, shelving is almost like a "personal" branch but where the state of things are stored server-side.

[jclausius]

Steven:

I went back to the source of the original post "in Vault, how does one allow incremental check-ins without risk of wrecking the build for everyone else?"

Let's talk about label. If a label was applied to a top level folder containing the project at a known point of stability, other users could do a GET on that label. The files retrieved with the GET would be at a known version which should provide the stability you are looking for. Do you think this would work in your use case?

If you feel I'm still off base, contact me through the e-mail button below this post, and I'll give you a call.

[StevenBlack]

Unless I'm mistaken, the problem with labels in Vault is
- a GET on a label is a (really) buried procedure relative to "Get Latest Version" and
- the label is apparently not visible in the History explorer (!?)

Then there's the issue of communicating labels, and managing label naming conventions across the team.

- ALSO, and this is killer, I can't seem to apply the same label to subsequent versions of a file. The error is "A label with the same name has already been applied to this object".

THEREFORE how is this supposed to work if our label is "Latest Stable Version"?



From what I am seeing, that can't work either without "unlabeling" prior versions, which assuming that works (I haven't tried) makes using labels, or at least an easy label like "Latest Good Development Version" a truly buried and convoluted procedure.

So the question remains: how is Vault supposed to work in a team setting with incremental regular checkins by deveopers?

If Vault can't work in this common scenario, you know, it's OK to say so. I'm interested in an effective and clean solution, not buried, convoluted, and ultimately un-enforcable procedures.

So can Vault handle incremental pre-QA checkins, or not?

[jclausius]

Unless I'm mistaken, the problem with labels in Vault is
- a GET on a label is a (really) buried procedure relative to "Get Latest Version" and
- the label is apparently not visible in the History explorer (!?)

That would depend on your definition of "buried". Perhaps the easiest way to get a label would be to invoke "Show Labels" on any file/folder, select the label you wish to retrieve, and invoke GET. Not as easy as "Get Latest" directly from the context menu, but not too overly complicated.

Then there's the issue of communicating labels, and managing label naming conventions across the team.

Yes, you would need to know the name of the label to GET.

ALSO, and this is killer, I can't seem to apply the same label to subsequent versions of a file. The error is "A label with the same name has already been applied to this object".

THEREFORE how is this supposed to work if our label is "Latest Stable Version"?

It won't work like that. Labels represent a unique version of any object (file or folder). A label of 'My Label' applied to two different versions would be ambiguous, and is not allowed. Label names can be whatever you would like as long as it explicitly names a single version of any object.

In the case you describe, I think you might want to look at Label Promotion or Label rename. Label Promotion allows users to change the make-up of a label. You can invoke this from any label within the "Show Labels" dialog. With label promotion users can edit the files or folders (add, edit version, or delete) that make up a distinct label. You could make modifications to the label to paint a picture of the label you would like to GET. Another option is to rename the "Latest Stable Version" to "Latest Stable Version - <Today's Date>", and then create a new "Latest Stable Version" label at the desired folder version.

So the question remains: how is Vault supposed to work in a team setting with incremental regular checkins by deveopers?
...
So can Vault handle incremental pre-QA checkins, or not?

If the goal is to isolate pre-QA checkins from approved changes, then you'll have a couple of different alternatives:

• Use Branch and Merge - In this scenario there are two top level folders (one created by branch). The "current (unstable)" branch is where current activity takes place, a GET from here will retrieve the latest and greatest code. The "stable" branch was created at a known version, and a GET from this branch retrieves code from a known/trusted code base. In this scenario, users are working out of different repository paths based on the kind of work they will be doing. Also, when changes are ready or have been approved, they can be merged over to "stable" branch in a controlled manner.
• Share and Pin - Like the branch option, there are two top level folders "current (unstable)" and "stable". Code located in "stable" has a dependency, so the "current (unstable)" folder is shared into the "stable" repository path, but the share is also pinned in order to stabilize the versions of objects, as they may have been modified in the other share in "current (unstable)." Note, this could also be implemented by sharing individual files and controlling version changes with pins to individual files. A Vault powertoy exists to help manage this kind of setup.
• Label w/ promotion - Labels are made at current milestones which could be driven by some event or date. Labels can be modified with "promotion" to reflect any minor changes which may need to be applied to current label definitions. Users do a GET the labels which they know to be a known stable version, and base their work off of that label.

Steven, I hope this helps you find a way to accomplish your goals. These are my own personal suggestions based on previous posts, so if anyone else would care to chime in with alternatives, please feel free to do so.

[StevenBlack]

Thanks Jeff, I'll digest that and report back.

You've been very helpful and I appreciate your attention.

In a sidebar, I wonder: why is Vault so much less functional than Source Offsite?

You see, if we could map more than one Vault folder to the same working folder (like we can with Source Offsite) , some (all?) of the difficulties mostly vanish. At least SOS makes branching while still using all the regular mainstream resources a breeze.

I just don't "get" that restriction. Client-site it's an easy kluge with disk mapping to use a different logical drive mapped to the same physical folder, in effect fooling Vault. But still. Next I'm going to hear, "don't do that because Vault will < insert warning here >".

I feel mostly handcuffed by Vault's limitations here....

Let me try what you suggest.

**--** Steve