Pinning/sharing behaviour

[Dalek]

Hi,

We have recently moved over from Source Safe to Vault and have noted that the pinning/sharing in vault seems to behave a bit differently. Previously, in Source Safe when we were preparing to make a release we would share from the History dialog of a our main solution folder which would produce a 'copy' in the shared folder with all the files pinned at the current version. This pinning, however would only be present in the shared folder and the main solution folder would be unaffected. Subsequently some developer would inevitably come up with some little file tweak which needed go into the release candidate for some reason and so we would unpin the affected file in the shared folder and then repin it to the new fixed version from the main solution before building the final release. It seems that this is not possible in Vault for the following reasons:

1) Pins in shared folders are not really supported i.e. a Pin is applied to the particular version of the file in all folders in which it is shared.

2) Because of this, the only way to create a distinct version pinned to a particular time is to use branch (or make a snapshot which is still a branch) in which case the pinning is not required but the version is of course no longer linked to the main solution and any last minute changes cannot easily be included in the branch. This would mean a new branch would need to be created which might not be convenient as other files in the main solution might also have moved on by then but not to a releaseable state.

So, is there a way to use Vault in the way we used to use Source Safe, can files be pinned in one folder of share but not in others and if not how would you recommend we use Vault in the situation where a release candidate version has been created and then a last minute change needs to be patched into it?

thanks


Keith

[jclausius]

Keith:

There is a distinction between Vault and SourceSafe "shared folders". Vault has the ability to actually share a folder, where SourceSafe (SS) does not. This is feature has numerous benefits.


In Vault, when you share a folder, the folder is what is actually shared. Since there is only ONE shared folder, a change in that one folder is reflected in all other shared places.

For instance, if a file is no longer required and is deleted, the file is no longer present in any of the other shared folders. If a folder is created under the shared folder, the new folder will be present in the other shared folder locations. If a file is added to the shared folder, it is present in all other shared folders as well. If a file or folder is pinned..., well you get the picture.


In contrast, when a share operation is invoked on a folder within SourceSafe, SS will NOT share the folder. Instead SS creates a NEW folder structure - an exact copy of the folder structure from the share location. These folders have the same name, but they are completely different objects within the SS repository.

Next SS will individually share each and every file (recursively) into the new folder structure. However, since the folder is not really shared, any changes made to that folder (add, delete, pin) only affect that folder.

This caused a lot of confusion, as most people expect the folder to be shared. They expected changes made to a shared folders to be reflected in the other shares.


If you still would like to duplicate SS's behavior, there is a work around:

A) Create a new directory with the same name as the folder containing the files you would like shared.
B) Share the "Files" (Select All and Share) instead of the folder into the new directory.

HTH

[christian]

Keith:

If you still would like to duplicate SS's behavior, there is a work around:

A) Create a new directory with the same name as the folder containing the files you would like shared.
B) Share the "Files" (Select All and Share) instead of the folder into the new directory.

HTH

Hi, I'm an evaluator getting ready to make the switch from source safe to vault. I use the exact same solution Keith posted for our releases. I am trying to figure the best approach to maintaining a snapshot of each release so as to provide for hot fixes while we carry on working on new features in the mainline. I think the solution you suggest may not be that workable in practice because you have to repeat your solution for each subproject (unless I'm interpreting things incorrectly). A big pain for us as we have 20-30 subprojects. Is there any way of avoiding having to repeat for each sub-project?

Another practice we follow with source safe that leads on from pinning to create our release snapshot. When we need to author a hot fix for a release we go to the files that need changing and perform a branch. After doing a branch you can view a files properties and in the Path's tab it will tell us its ancestry ie where it was branched from and what version.

Can you tell me where I can find this kind of information about branch ancestry in vault?

Now I appreciate this may not be the most appropriate way of working with vault so maybe you can suggest a better approach. Again the final solution needs to support being able to easily incorporate current work into a release candidate from the main line (the term here is probably rebasing the release candidate code line with the mainline).

Thanks in advance.
Christian

[jclausius]

Christian:

As my original post stated, it was a manner to replicate SS' behavior. As you mentioned, the suggestion is not pain free.

Now I appreciate this may not be the most appropriate way of working with vault so maybe you can suggest a better approach.

I'd take a look at a couple of different approaches:

1) Label -> (future Branch) - With this approach, the label is applied to a particular folder or file when you reach a stable point in the dev cycle.

When you deem the time is right to start making changes along this code path, the label is then branched into a new part of the tree, and work can begin within the branch.

2) Snapshot - Snapshot will create a new branch within the tree, but the Snapshot's folder is pinned - not allowing changes. The idea here is that Snapshot is creating a "picture" of the folder for a given point in time, and it is not yet ready for editing. When you deem the time is right to start modifications, simply unpin the folder.

There is one side effect to be aware of with Snapshots. Snapshots will bloat your source tree. Larger trees require more server side resources (CPU cycles + memory) while performing SCC operations.


Take a look at each option. Either one should work, some people feel more comfortable with the snapshot approach, while others prefer labels.

I'll answer your other questions in a follow up post.

[jclausius]

Another practice we follow with source safe that leads on from pinning to create our release snapshot. When we need to author a hot fix for a release we go to the files that need changing and perform a branch. After doing a branch you can view a files properties and in the Path's tab it will tell us its ancestry ie where it was branched from and what version.

Can you tell me where I can find this kind of information about branch ancestry in vault?

The branching information is found in the history for the item.

[jclausius]

I think I should point out something in Keith's post. He was asking questions about the case where an object was shared from history into a SHARED folder. My response addressed the differences between Vault which does support folder share, and VSS which does not.


Upon re-reading your post, I don't believe you have that same scenario, and your situation might be different.

Assuming you are not worried about the pinned status of sub items of a shared folder, simply:

1) Show History on the folder in question.
2) Highlight the version of the folder you "know" contains" the correct info.
3) Click Share on the History explorer, and choose the Share's destination.

This operation will share the folder within your tree, and the root of that folder is pinned. Note, this is another big difference between Vault and SS. Vault supports Folder pin, VSS does not.

Please let me know if I mis-interpreted your post.

[christian]

Hi Jeff,
Thanks for the very prompt reply. I've tried to follow your instructions and
don't seem to be getting the results you indicating. Here's the problem:

1) Show History on the folder in question - fine
2) Highlight the version of the folder you "know" contains" the correct info - fine. I opted here to view "View folder history by version"
3) Click Share on the History explorer, and choose the Share's destination - I click Share and nothing happens. I'm not prompted with a destination to share.

I tried steps 2 and 3 this time opting for "View folder history by item". Now when I ask the highlighted folder I get the follow message:
"Object reference not set to an instance of an object". Sounds like this is an exception message?

Am I doing something wrong?

[christian]

Christian:

1) Label -> (future Branch) - With this approach, the label is applied to a particular folder or file when you reach a stable point in the dev cycle.

I'd like to explore the use of labelling in combination with using the label promotion feature to "tweak" what goes into a release candidate, using your suggestion of branching from the label and working from this branch to author a hot fix while new features are developed on the mainline.

I played around trying to do label promotion but without much success. The help file says, "Label promotion is accomplished from within the Show Labels dialog"

So I selected "Show labels" on the folder that I had previously labelled. I was presented with a dialog box with the label that had been applied to this folder. I could find no where to do things like:
associate with this label a file created after the label;
change the version of a file associated with the label
disassociate a file that's currently associated with the label.

How would I go about doing this?
Thanks in advance.
Christian

[jclausius]

Now when I ask the highlighted folder I get the follow message:
"Object reference not set to an instance of an object". Sounds like this is an exception message?

Am I doing something wrong?

I just checked the bug list. This is a current bug, which will be fixed in Vault 2.1. Sorry about that.

[jclausius]

I could find no where to do things like:
associate with this label a file created after the label;
change the version of a file associated with the label
disassociate a file that's currently associated with the label.

How would I go about doing this?
Thanks in advance.
Christian

I don't believe any item in a label can be promoted "forward" to a version in a branch, so you'll need to take care there.

In any case, label promotion is accomplished by:
1) Show labels on the main item
2) Highlight the label
3) From the menu choose "Label" -> "Promotion..." You should see the Label Promotion dialog.
4) To add a file / folder, choose a folder and invoke "Add". Note, you can only add objects found in the current version of the folder, but not found in the label.
5) To remove a file / folder, chose the folder and invoke "Delete".
6) To change version, highlight a file, and change the version of the file to any version found in the file's history.

HTH

[christian]

In any case, label promotion is accomplished by:
1) Show labels on the main item
2) Highlight the label
3) From the menu choose "Label" -> "Promotion..." You should see the Label Promotion dialog.
4) To add a file / folder, choose a folder and invoke "Add". Note, you can only add objects found in the current version of the folder, but not found in the label.
5) To remove a file / folder, chose the folder and invoke "Delete".
6) To change version, highlight a file, and change the version of the file to any version found in the file's history.

D'Oh, I think my problem here was selecting an inherited label. I notice that the Promotion menu item is greyed out and that’s why I failed to notice the feature! Sorry for bothering you on this one.

I had a play with this feature and I got to say that in conjunction with being able to view the composition of a label as a tree and driving the promotion from this view is 10x more powerful than src safe. I think the limited support you get with src safe to view what’s in a label is why I never really used it before. Lovely work :-)

I don't believe any item in a label can be promoted "forward" to a version in a branch, so you'll need to take care there.

I kinda thought that. What I was thinking here is once you've branched from the label if you want to baseline this branch from the mainline you would do a merge with the mainline as the origin and the branch as the target?
Talking about branching from a label, how would this be achieved from the menu? I couldn't find any mention of this from the help file.
Thanks in advance.
Christian

[jclausius]

What I was thinking here is once you've branched from the label if you want to baseline this branch from the mainline you would do a merge with the mainline as the origin and the branch as the target?

Yes, that would work, but the label would have to be applied to the branch, not the baseline.

Talking about branching from a label, how would this be achieved from the menu? I couldn't find any mention of this from the help file.

Highlight the item in Show Lables, and invoke the branch command.

[christian]

What I was thinking here is once you've branched from the label if you want to baseline this branch from the mainline you would do a merge with the mainline as the origin and the branch as the target?

Yes, that would work, but the label would have to be applied to the branch, not the baseline..

Not sure whether I follow you on this one. I'm assuming here that I've labelled the mainline (trunk) in preparation for a branch later on if I need to author a hot fix. I carry on developing new features on the mainline. I then find I do need to author a hot fix so I go and branch from the label, coding the hot fix on this branch. Now I want some changes I've made in the mainline merged into the branch as part of the hot fix. This is where I though I'd be doing a merge from the mainline into the branch, probably hand picking the changes in the mainline I want to merge into the branch. Labelling I'm assuming does not play a part in this whole process other than to provide a reference point from which to branch?

Talking about branching from a label, how would this be achieved from the menu? I couldn't find any mention of this from the help file.

Highlight the item in Show Labels, and invoke the branch command.[/quote]

Tried this but I notice that the branch is greyed out. What am I doing wrong?
Thanks again
Christian

[jclausius]

Not sure whether I follow you on this one. I'm assuming here that I've labelled the mainline (trunk) in preparation for a branch later on if I need to author a hot fix. I carry on developing new features on the mainline. I then find I do need to author a hot fix so I go and branch from the label, coding the hot fix on this branch. Now I want some changes I've made in the mainline merged into the branch as part of the hot fix. This is where I though I'd be doing a merge from the mainline into the branch, probably hand picking the changes in the mainline I want to merge into the branch. Labelling I'm assuming does not play a part in this whole process other than to provide a reference point from which to branch?

Scratch my comment. I assumed you wanted to fix the Label's contents through promotion of changes which occurred in the branch.

What you've described here - merging from the trunk to the branch - is pretty much correct.

Tried this but I notice that the branch is greyed out. What am I doing wrong?

Has the label been modified through promotion? A modified label does not represent any known version of a folder found in any historical tree, and cannot be branched.

[Guest]

Has the label been modified through promotion? A modified label does not represent any known version of a folder found in any historical tree, and cannot be branched.

Blast, you're right, I've used label promotion to tweak the composition of the label. Now that's a real dissapointment. Can you see what I was trying to do?...
Label once sufficently happy that the latest version can be released;
Maybe tweak the composition of this label for a few last minute bugs;
Release (knowing that we can go back to the label at any time);
Carry on working on new features on the mainline;
Spin off a branch from the label when the need arises to create a hot fix.

Back to the drawing board!

Maybe I look at the ideas about sharing and pinning again....

One of your suggestions based on this idea of sharing and pinning was to:

1) Show History on the folder in question.
2) Highlight the version of the folder you "know" contains" the correct info.
3) Click Share on the History explorer, and choose the Share's destination.
This operation will share the folder within your tree, and the root of that folder is pinned.

However I posted on Wed Sep 15, 2004 9:55 am that I had the following problems with this:

1) Show History on the folder in question - fine
2) Highlight the version of the folder you "know" contains" the correct info - fine. I opted here to view "View folder history by version"
3) Click Share on the History explorer, and choose the Share's destination - I click Share and nothing happens. I'm not prompted with a destination to share.

Any thoughts on what's going wrong.

Thanks for your continuing help!
Christian
Going back to my post dated Wed Sep 15, 2004 9:55 am