Pinning back to version before branch

[robe070]

Hi,

Vault version 4.1.3.18336
We have just branched a large set of files. We then found that a last minute change had a defect that required a large amount of effort to fix. We needed a build ASAP to handover to QA so we attempted to pin back to a version prior to the branch. But you can't - its disabled. Can this restriction be lifted?

Also note that if a version after the branch is right-clicked, the pin option becomes enabled. Its then enabled for all the versions prior to the branch as well. If you then select pin an error occurs. Clearly its not meant to work at the moment.

regards

Rob Goodridge

[Beth]

In order to make a branch be a version prior to that branch, you will need to delete the branch, go to the history of the original location, and branch at the version you want. Even though there is a link to the history prior to the branch, that history is not copied. Because of that, you can't make the branch take part of the history prior to the branch.

On the other pin you tried and failed, what was the error given? If an item is checked out, it can't be pinned.

[robe070]

Firstly, its mostly academic. We have effectively rolled back to the version of particular files that we want by checking in a new version.

What do you mean by "you can make the branch take part of the history prior to the branch". Apart from the link and not actually copying the history, what else can you make it do and how? I know of no options when branching. If you branch at an earlier version than the tip, all the branch has is the versions up until the version you branched at. None of the subsequent versions will be in the branch.

We find the Vault method of branching a severe limitation. We knew of it before we purchased it and still did because of all the other great things about it. Still its severely limiting. Its the only version control system I know that when branching loses connection to its origin. This brings in complications like having to merge changes into both your trunk and branch even though the branch needs to be exactly the same as the trunk. This is very common in our product and I would expect it to be the same in most other products. I suspect its fundamental to the Vault design, but if there was any possibility that a branch could truly be a branch and not a completely separate entity then I want it ASAP!

On the other issue, its part of the same discussion, its not separate. Also, its not important. If what I wrote is not sufficient to reproduce it at your end, don't worry about it. I'm not

regards

Rob Goodridge

[Beth]

What do you mean by "you can make the branch take part of the history prior to the branch".

Sorry, that was a typo. I've corrected it to can't. In order to go back to prior to a branch, you need to delete the branch, and make it from the history of the original folder you were branching.

Still its severely limiting. Its the only version control system I know that when branching loses connection to its origin.

I don't think that's an accurate description. It can see the history and you can get on it. It's just that before the branch, the details on those check ins all relate to the original location and not the branch. A branch is it's own entity even though it was built off of the history of the original location.

but if there was any possibility that a branch could truly be a branch and not a completely separate entity then I want it

The only way to have that is to share instead of branch. Then it's essentially a copy of the area shared from and always matches. Could it be that what you really want is a copy? Do you ever merge from branch to the original location? What purpose do your branches serve?

On the pin issue, I tested it and the error says it can't pin before the branch. This is running into the same issue as trying to roll back to prior to the branch. It won't be able to force the branch to be a version prior to the branch.

[robe070]

Its an accurate description from the perspective of knowing other version control systems. You can see how different branches are related to each other in a tree-like relationship. In Vault, seeing text in a branch is not the same as actual versions. Its pretend branching.

But to maybe a more fruitful discussion.

We have an extensive product for which we support at least 3 major versions plus various service packs on each plus patches on each.

Each release must only have applied to it the changes relevant to that release. By branching we isolate the changes that get into a release. Only what we merge in to a release gets in there. Generally we make the change in the Trunk, or latest, version and then apply it to the branch and potentially also to the patch. For the patches we already have a sparse tree. We only share & pin into the patch what has actually changed.

This works. Connections between branches are not obvious and there is no tree-like representation of this, but it does work.

Labels have issues which I can't remember specifically that mean we can only use them to mark something significant. We cannot actually build from them.

Of course if we shared and pinned when creating the branch, this would isolate the change. We could move the pin when the Trunk and Branch are the same. We could unshare and merge in changes when they are not the same. This makes merging more difficult as you can't just merge in the whole changeset. Or maybe you can? Does the merge tool recognise its the same file and just move the pin?

And of course, once you've unshared it they are now separate files with no obvious connection between them.

And what about disk space? Wouldn't copying to branch use up much more space than standard branch, and in fact as time went on each successive branch of the Trunk would be bigger than the last branch because it has more history?

[Beth]

Connections between branches are not obvious and there is no tree-like representation of this

Ok, now I see what you were looking for. Yes, we don't have something that provides that information yet. I could make a feature request if you would like.

Labels have issues which I can't remember specifically that mean we can only use them to mark something significant. We cannot actually build from them.

If you would like to troubleshoot that, then just provide details and start a new thread.

We could move the pin when the Trunk and Branch are the same. We could unshare and merge in changes when they are not the same. This makes merging more difficult as you can't just merge in the whole changeset. Or maybe you can? Does the merge tool recognise its the same file and just move the pin?

When you unpin the file, Vault will apply everything from the point it was pinned forward coming from the other side of the share until they match exactly. There really isn't merging necessarily. Now, if you were merging changes in from a third location using the merge branches function, then you would only need to merge to one side of the share and the other side of the share will make itself match. Then you can pin again.

And what about disk space? Wouldn't copying to branch use up much more space than standard branch, and in fact as time went on each successive branch of the Trunk would be bigger than the last branch because it has more history?

You are correct. I may not be the best idea for this case after you explained further.

[robe070]

Connections between branches are not obvious and there is no tree-like representation of this

Ok, now I see what you were looking for. Yes, we don't have something that provides that information yet. I could make a feature request if you would like.

Please make a feature request.

We could move the pin when the Trunk and Branch are the same. We could unshare and merge in changes when they are not the same. This makes merging more difficult as you can't just merge in the whole changeset. Or maybe you can? Does the merge tool recognise its the same file and just move the pin?

When you unpin the file, Vault will apply everything from the point it was pinned forward coming from the other side of the share until they match exactly. There really isn't merging necessarily. Now, if you were merging changes in from a third location using the merge branches function, then you would only need to merge to one side of the share and the other side of the share will make itself match. Then you can pin again.

The point of this was that I have one changeset with some that just require unpin/repin and others that are already separate files and need to be merged and others that are pinned back behind the tip and now need to be unshared and merged. Does the Merge Tool manage all this? If not, its too complex and will lead to developer mistakes. Much better just to have non-shared branch and merge every file in in one easy action.

[Beth]

I found a feature request very similar to yours, so I have added your vote and comments.
F: 9219

The point of this was that I have one changeset with some that just require unpin/repin and others that are already separate files and need to be merged and others that are pinned back behind the tip and now need to be unshared and merged. Does the Merge Tool manage all this? If not, its too complex and will lead to developer mistakes. Much better just to have non-shared branch and merge every file in in one easy action.

This does sound very complex. You would like you might be better served by one branch instead of the mix. The merge tool won't unpin things.