Very disappointed with Vault Standard 6.0 feature list

[robe070]

I was very disappointed to see that neither Merging or Shelvesets are getting a makeover in version 6. The 3 new features described: content searching - that's what an editor is for; Event Notification - by email works very well for us, no requirement at all to integrate into the Client; Classic Client updates - it works already.

Merging and Shelvesets have major limitations that if fixed would massively increase our productivity or quality or both. There are plenty of posts already about the limitations. Please address them in 6.0.

In summary, 3-way merge and ShleveSets with Virgil's changes.

I'll presume if the changes are not in 6.0 that you are extremely unlikely to do them and we will have to make our decisions accordingly (a mistaken evaluation got us into this situation).

[jclausius]

I was very disappointed to see that neither Merging or Shelvesets are getting a makeover in version 6. The 3 new features described: content searching - that's what an editor is for; Event Notification - by email works very well for us, no requirement at all to integrate into the Client; Classic Client updates - it works already.

Merging and Shelvesets have major limitations that if fixed would massively increase our productivity or quality or both. There are plenty of posts already about the limitations. Please address them in 6.0.

In summary, 3-way merge and ShleveSets with Virgil's changes.

I'll presume if the changes are not in 6.0 that you are extremely unlikely to do them and we will have to make our decisions accordingly (a mistaken evaluation got us into this situation).

Rob,

As I stated in an earlier comment on the vaultblog, this list addresses the majority of customer requests for new features. However, I should point out it highlights new development and is not all inclusive for small tweaks and fixes. For example, you may want to read through your thread - Merge Branches tool to limit versions where we talked about adding certain items to Vault 6.

In regards to shelving, Virgil Smith's suggestions have been entered into the system. As I mentioned in the vaultblog comment, nothing was planned, but we'll evaluate Virgil's suggestions along with all other requests and improvements to see if/how they can be applied to Vault 6.

[robe070]

Jeff, its the minor changes that you think are major and the major faults with existing features that you treat as minor. If you haven't listed changes to Merge and Shelvesets as major changes in 6, then you are not doing them or are only making minor cosmetic changes, much like the 'major' features you have listed.

Truly, Vault Standard has received only minor or half implemented changes for a number of releases, and thus can be presumed to be a minor part of your development program. It looks like its just on a maintenance program and 'what can we list so as to make it look like we are continuing to put significant effort in' program.

Why other users do not see a 3-way merge and therefore branch relationships as major omissions I do not understand. These features make a significant difference to parallel version development, and for all but minor projects, the lack of them make parallel version merging completely impractical. I can only presume that the majority of users do not know what they are missing.

[jclausius]

Rob,

Of the features listed: Content Search - nothing like an editor based search, but rather a full index based search of all files in the repository - Vault Standard feature. Event Notification - email, email digest, app messages - Vault Standard feature. Vault Classic Client restructuring so it works in SQL Server Management Studio and other IDEs besides Visual Studio -> Vault Standard feature. By no means is Vault 6 a 'maintenance' release, but rather a release with key functionality requested by an overwhelming number of customers.

With that said, I would like to improve Vault in other areas, such as Merge Branches. Vault 6 will be adding a Merge Branches feature to filter history by dates. Also, I will be looking at other requests for merge branches, for example, labeling "source" folders after the merge, comment formatting, and skipping wizard pages.

Finally, I'm not sure I understand what you're getting at by "3-way merge" as I'm thinking about file merges, and I'm sure you are talking about something else. I cannot find a post from you regarding this. Could you please describe what you are asking for, and how it would apply in Merge Branches?

[GregM]

Vault 6 will be adding a Merge Branches feature to filter history by dates.

Thank you! Will this be like the history where you can set number of days, and can you set the default?

[jclausius]

We haven't discussed implementation yet. All I know is I was merging the Vault 5.1 branch into our main trunk, and it was taking a bit too long not to mention the amount of data I needed to sift through.

There needs to be some kind of filtering / merge markers that makes this a bit less tedious.

Any/all requests for this are welcome.

[robe070]

Indeed, it does take a long time to merge a parallel version back to the Trunk. This post discusses some possible solutions: http://support.sourcegear.com/viewtopic ... 030#p43030. Its especially relevant when your merge to the Trunk takes place periodically. What Vault is missing is the knowledge that:
1) The branch was created from a particular version of the Trunk - called Parent Base.
2) That changes up to a particular version have been merged to the Trunk - called Branch Base.
3) Comparing Branch Base to current branch tip (or latest version chosen) and merging ONLY THOSE differences into the Trunk tip - 3-way merge.

I didn't actually use the term 3-way merge previously, but this is what I mean.

I haven't attempted these kinds of merges for a while as they are a pain in Vault currently, so I can't remember the precise issues with the UI, but it was something like all changes that have already been merged into Trunk being shown again and thus needing to check through those as well, and not just the latest differences.

As I said previously in this post, if the general user base understood what this would give them, I'm sure that a large number would vote for this over anything currently proposed as major in 6.0.

Current 6.0 major features:
1) We already use an Index search in Visual Studio.
2) We already have email notifications of Vault changes
3) We don't use SQL Server Management Studio because we do cross-database development

5.x was equally useful to us. So nothing for us since 4.x.

Other merge post: http://support.sourcegear.com/viewtopic ... 228#p43228

[jclausius]

I haven't attempted these kinds of merges for a while as they are a pain in Vault currently, so I can't remember the precise issues with the UI, but it was something like all changes that have already been merged into Trunk being shown again and thus needing to check through those as well, and not just the latest differences.

Exactly! That is the area we'll be looking at - whether it be filtering by date or some other mechanism.

[robe070]

I haven't attempted these kinds of merges for a while as they are a pain in Vault currently, so I can't remember the precise issues with the UI, but it was something like all changes that have already been merged into Trunk being shown again and thus needing to check through those as well, and not just the latest differences.

Exactly! That is the area we'll be looking at - whether it be filtering by date or some other mechanism.

Exactly NOT what I am talking about! Source code line changes being shown in the merge view when you are reviewing the changes file by file, not the list of versions. All filtering does is redcuce teh time to show the list of versions. It does not help with Vault not understanding the relationship between branches.

[jclausius]

Rob,

Sorry. I'm talking about changes to the Merge Branches tool, and the history which will be merged into the destination folder.

Your post states, "Source code line changes being shown in the merge view when you are reviewing the changes file by file," While the Merge Branches does not show you changes file by file, the resulting pending changes does have that information. You can see the changes file by file before you merge.

Are you saying you would like to see this information within the Merge Branches dialog? Can you elaborate more about making Vault understand "the relationship between branches"?

[robe070]

Rob,

Sorry. I'm talking about changes to the Merge Branches tool, and the history which will be merged into the destination folder.

Your post states, "Source code line changes being shown in the merge view when you are reviewing the changes file by file," While the Merge Branches does not show you changes file by file, the resulting pending changes does have that information. You can see the changes file by file before you merge.

Are you saying you would like to see this information within the Merge Branches dialog? Can you elaborate more about making Vault understand "the relationship between branches"?

I am describing reviewing the changes with a difference tool like DiffMerge. This particular issue is not about listing the version history. The difference is calculated using the two files in each branch. What is missing in the difference tool view is the point at which the changes in the Origin are to be applied. Its called a 3-way merge. The 3rd file is the state of the origin before the versions that are being applied. The merge tool would then show that as the base, the Origins latest version being merged as the comparison file (diff these two files), the Target file and apply these changes to the Target file showing the result in a fourth window.

What is seen as far as differences is then limited to just the versions being worked on and not mixed in with other differences. I'm not sure if DiffMerge can do this as I have integrated kdiff into Vault (easy to do). Kdiff can definitely do it.

[jclausius]

Rob,

Three way merging is available during normal operations. This happens when a file gets into a "needs merge" state. Most merge tools, including SourceGear DiffMerge from within Vault, already handle this. You invoke "Show Merge" and you can look at repository, common ancestor, and the middle pane is usually your working folder.

In regards to merging from a branch, I can't say I've ever run the Merge Branches tool on a branch where files were already edited (or worse yet, in "needs merge" state). In this case, there might be multiple common ancestors (i.e. two merges would have to occur - repository to working folder and branch to working folder). Since I haven't tried it, I'll run some tests to look at what would happen if you merged into a working folder in which have active changes.

At least this will paint a picture of what use case you would like handle.

[robe070]

Rob,

Three way merging is available during normal operations. This happens when a file gets into a "needs merge" state. Most merge tools, including SourceGear DiffMerge from within Vault, already handle this. You invoke "Show Merge" and you can look at repository, common ancestor, and the middle pane is usually your working folder.
.

I thought you needed 4 panes to do a 3-way merge, not 3.

Anyway, if the Common Ancestor is the point at which the Branch occurred, then when performing regular merges from Branch to Trunk, one or other of the panes (or maybe even 2 of them?) will show all the differences since the branch, not just the changes that this set of Versions is applying. Thus the developer must re-review all the changes already reviewed in previous merges. After even a couple of iterations it becomes very tedious.

This is about doing Feature Branches as described in SVN: http://durak.org/sean/pubs/software/ver ... terns.html.

John O'Niell has already stated to me in an email that "Our engineering team understands [Feature Branches]". Maybe one of them can help you understand the problem space.

In regards to merging from a branch, I can't say I've ever run the Merge Branches tool on a branch where files were already edited (or worse yet, in "needs merge" state). In this case, there might be multiple common ancestors (i.e. two merges would have to occur - repository to working folder and branch to working folder). Since I haven't tried it, I'll run some tests to look at what would happen if you merged into a working folder in which have active changes.

I'm not talking about that either.

[jclausius]

I thought you needed 4 panes to do a 3-way merge, not 3.

It might depend on a tool's implementation. For SourceGear DiffMerge, it presents the three way merge in three panes.

John O'Niell has already stated to me in an email that "Our engineering team understands [Feature Branches]".

I'll check with John to see what data he's gathered.

Thanks.

[jclausius]

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.