Very disappointed with Vault Standard 6.0 feature list

[GregM]

While you're working on Merge Branches, can we have user filtering and non-contiguous selections too?

[jclausius]

Greg,

In regards to filtering, besides what has already what has been discussed in this post and in others (with Lynn), what are your other ideas?

[GregM]

Sorry if that wasn't clear, "user filtering" == "filtering by username".

I generally only want to merge my own changes, so an option to include only my changes, changes from all users, or changes from selected users like in the history filtering.

[robe070]

Rob,

One of the biggest problem with Vault's presentation in this regard is deciding what was last merged for subsequent merges. We'll look to see if we can improve this when it comes implementing improvements in Merge Branches for Vault 6.

Thats exactly it. First merge is fine. Each succesive merge gets more and more littered with previous changes.

[jclausius]

Sorry if that wasn't clear, "user filtering" == "filtering by username".

I generally only want to merge my own changes, so an option to include only my changes, changes from all users, or changes from selected users like in the history filtering.

Understood.

and

Thats exactly it. First merge is fine. Each succesive merge gets more and more littered with previous changes.

Understood.

[joshyeager]

I'm not as concerned about Vault 6 as Rob is, but I do want to reinforce his request for better merge support. We make a branch for each major version that we release to customers, so that we can patch them if necessary. This works fine in most cases, because we can just merge those patches back into the trunk. But, we occasionally encounter a situation where a customer needs a patch to fix a bug that we have already fixed in the trunk. In that case, our options are to merge a few changes from the trunk into the branch, or to re-implement the fix in the branch. Either way, the next time we try to merge the branch into the trunk, it becomes quite difficult to exclude the changes that were made for that particular fix. We can't include them, because the fix in the branch is usually slightly different from the fix in the trunk, either because of other changes in the code or because the branch has a stripped-down version of the fix.

We have also had a few situations where we had to make a temporary feature branch because a customer needed us to implement a new feature ahead of our normal release cycle. In those cases, we would make a branch from the version the customer was running, and implement the new feature in that branch. Once it was done, we needed to merge the new feature into the trunk, which was very difficult because the branch was made from another branch instead of directly from the trunk. Since Vault didn't realize that fact, it would try to merge a lot of code that should not be merged.

Eric Sink wrote an article in 2009 which describes the behavior that I would hope to see in these cases. http://www.ericsink.com/entries/merge_history.html. When I saw it, I was hoping that meant that Vault would be getting that feature soon.

[GregM]

While you're working on Merge Branches, can we have user filtering and non-contiguous selections too?

I see these didn't make it into Vault 6. Any timeline for adding these features?

I'd also really like to be able to disable the search for modified files in the merge destination folder. It seems to be taking longer and longer these days. At least subsequent merges into the same destination folder seem to be faster on this step.

[jclausius]

Unfortunately, non-contiguous ranges proved to be a more difficult challenge and didn't make it into Vault 6. It is a feature currently scheduled for the next major release of Vault, "Vault 7."

I'll also add a feature request regarding to re-visit the scan for modified files. Don't know if we'll find anything, but at least we'll give it a once-over to see if there are any glaring performance issues.