"Commit selected" removed from context menu

[davenovak]

Today we upgraded our Vault server (and all clients) from Vault 5.0.3 to 5.1.1. Though the upgrade itself was painless, a number of developers here have already commented on the fact that you can no longer select files in your Pending Change Set and then right-click to select Commit Selected. Why was this menu item removed?

This makes no sense to me, especially since Undo Selected and Shelve Selected are still part of this context menu.

Many of us here would really appreciate it if you would add that feature back to the Pending Change Set context menu.

Thank you!

[lbauer]

Thanks for your feedback. If the user checks the files they want to checkin, then click the Commit command on the Pending Change set menu bar, then those selected items will be checked in.

But I can see where you might want to select a range without having the click each checkbox -- is that the case?

[davenovak]

So what you've done now is forced extra steps on the user to check in files. It is exactly as you say, you now must:

• 1. Click the check box on the files you wish to check in
  2. Click the Commit button.

This is totally different than the way everyone I know has trained themselves to check in files using Vault. Those that I work with simply select a range of files from the list and then right-click and pick Commit Selected from the context menu. It's very fast and easy, but more importantly, it's how we all have done commits for the past 4+ years using Vault. Having to click the check boxes and then move the mouse all the way over to the Commit button feels like a real chore by contrast.

Frankly I'm just surprised that you removed a feature that was working perfectly well, only to replace it with one that is less efficient. Furthermore, as I stated in my previous post, I would point out that Undo Selected and Shelve Selected are still part of this context menu. So why not Commit Selected?!?

Please add 50 votes (user count in our office) for restoring this feature.

Thank you for listening.

[lbauer]

I think some of the changes were primarily for new integration functionality in the Vault Pro client (selecting transactions to be associated with work items) But they appear to add extra steps in the Vault Standard Client.

I've logged work item 15793 to see how we can fix this in a future release.

Sorry for the inconvenience in the meantime.

[jclausius]

Dave,

In regards to your question of why...

In the next release of Vault, there will be an alternate treeview for change sets. Checkboxes work here as selecting / deselecting a tree node will modify files in that folder. At this point, a checkbox for selection in a listview will have the same meaning as a check in the treeview. The goal is to present a consistent UI across views. This also satisfied some complaints we had about losing the change set selections when inadvertently clicking the list.

I haven't seen negative feedback about the UI change until your post, but we aim to please. Perhaps there may be way that allows an either/or UI for change set items.

I'll have to think about this some more and see if there is a way to satisfy both conditions. Thanks for your feedback.

[davenovak]

Jeff --

As you evaluate various approaches that would allow an either/or UI for change set items, I would think that you could pretty much mimic the Undo Check Out... context menu behavior. In other words, when the user right-clicks in the Pending Change Set tab, the new Commit Selected... item would apply only to the highlighted items in the list (regardless of whether or not anything is actually checked).

That seems trivial to code, is very intuitive for the user, and seems to fit your either/or UI goal.

Hope this helps.

--Dave Novak

[jclausius]

Dave,

The check boxes for Vault can disappear, it's the case where the same class is being used with Vault Pro, and the selection is a bit trickier. I'll twiddle with some subclassing to see what shakes out.

Thanks for the feedback.

[davenovak]

I think it's also worth pointing out that the Search tab still contains a Check In... context menu option when you right-click on Edited items on the Search tab. Therefore, it doesn't seem like it would be hard to add the same back to the Pending Change Set tab.

[jclausius]

It's not a matter of technology, but rather what controls are in place. The pending changes list view control is coded differently than the list view control on the search results. As mentioned, there would need to be some new subclassing here.

[jclausius]

You also raise a good point that there is an inconsistency between check boxes and selections in search results and the pending change set. I'll need to add that into the equation as well.

Thanks for bringing that up.

[davenovak]

Indeed -- the inconsistency between these tabs is really the most important thing to recognize.

[joshyeager]

My users have noticed the same thing that Dave reported. In previous versions, if you had a lot of files checked out and wanted to check in five or ten of them, you could just shift-click on the first and last files, and then click Commit. Now, you have to check each file individually before you can commit them. It is also a bit annoying to have to click the Commit button instead of using the right-click menu.

[jclausius]

Josh,

Thanks for the feedback.

[iain.waddell]

Add me to the list. It's been bugging me since I upgraded. It's just SO irritating.

As a partial workaround I've found using the VS2008 view allows me to commit but it only shows the files for the current solution, so it's not great if you've got to commit files outside of the solution.

Iain

[iain.waddell]

I've logged work item 15793 to see how we can fix this in a future release.

Is there any way we can follow the progress of this work item?

Iain