Community
Participate
Working Groups
- In the navigator (or packages view) select two files. - Choose Replace With from the popup menu - Several of the options on the submenu are grayed out. We need to enable the 3 grayed options (local history, version, previous) otherwise its too frustrating because the user has to replace one file at a time.
Replacing with a version involves opening a compare editor; I would suggest that this one is not enabled for multi-select. The other two (Replace with previous and local history) are from the compare framework. Moving to compare.
Yes I realize a compare is involved. But forcing me to manually have to select each file one at a time and then choose the option is grievous. The better answer is for the UI to be able to accomodate showing multiple files. After all , the sync view can do it. Several other folks have commented on similar frustration at having to do a file at a time.
I agree that "replace with" should be available on a multiple selection. However, to address this problem we should first solve the Replace With inconsisteny in the UI. * replace with version: opens a compare editor * replace with local history: shows a dialog with available "versions" and the user can select which one to add to the workspace. No comparison is performed as part of the replace with action. I propose to use a dialog in both cases. The rational is: 1) the replace with version compare editor is problematic. - why do I have to do a compare first when I want to replace a version. This requires fetching up to 3 versions from the repository and slows down the operation. When I want to do a comparison and then I use the Compare with Version operation. - there isn't enough space for the version information in the editor. In particular when the structure pane is shown as well. 2) a dialog makes it straightforward to support a multiple selection by presenting the dialog for each selected element (cancel aborts the entire sequence). Compare should support multiple selections for replace with local history and replace with previous. I've filed a separate bug for this limitation 9135. Moving to VCM for consideration of the proposal.
Agreed with all of Erich's comments / solution-proposal.
We've gone around in a circle; the proposal is exactly what we had pre-1.0. A chronology: -We popped up a dialog with a table of available revisions. -People said that the name of the available revision wasn't enough info. -We put the history in the dialog (i.e. like in the resource history view). -People said that they wanted to see the contents of the files in the dialog. -We put the left-and-right compare view in the dialog as well. -People complained that the dialog was modal and they couldn't do anything else while it was open. -We got rid of the dialog and combined it with the functionality of the compare with version editor. Putting a dialog back in would revert to the behaviour that received much negative feedback.
In 2.0, we support mutli-select for "repalce with branch or version" and "replace with latest". We do not support it for "replace with revision" since revisions are specific to each file so a multi-select is not appropriate.
I am unclear how this can be considered resolved. I think Eric's comment perhaps need to be taken into a separate defect but there is clearly a usage problem. James is concerned the proposal may be similar to an original approach that received negative feedback, but unfortunately the same is true of the current solution. This needs to be looked at again. With respect to the replace with revisions, the fact that the revision is separate for each file doesn't really matter. The current approach forces me to repeatedly select item, menu option, choose replacement, over and over for each item. Even the less than ideal ENVY/Developer (and VAJ approach) where you could multi select then it gave you dialogs asking about each was better. I am sure there we can do better than the VAJ (hence not recommending that). This should not be considered resolved.
Sorry, I was looking at the problem with too narrow a focus (i.e. CVS). If I understand correctly, the issue you are concerned with is enabling the user to replace multiple files in a single operation where each file may (or may not) have a different set of timestamps/identifiers. The desire, then, is to allow the user to select the paricular version of each file they want loaded.
Sounds right (assuming I read your comments correctly).
Created attachment 10586 [details] This patch adds multiselect to the "replace from local history" action My sob story: I recently did something incredibly stupid and needed to restore my entire workspace from the local history. I realized that it would take me less time to add multiselect to the "replace from local history" action than it would be to hunt through the local histories of the thousands of files in my workspace. This patch worked well enough to recover my workspace, but it still has some bugs. I spent a couple hours trying to turn it into a "real" feature, but it's starting to take too much time so I'm just posting the patch here in its current state. Hopefully this will be helpful. :-) Here's how it behaves: When you do a single-select, the existing "local history" action runs. When you do a multi-select, it opens a dialog showing all the changes in your selection in chronological order. You pick the point in time you want to roll back to, and it restores all files in your selection back to the state they were in at that time. Known bugs: 1. No progress dialog is shown when it first searches through the local history (it just pins the UI thread until it's done). 2. After doing the replace, it doesn't always trigger a build and old problem markers continue to hang around (I suspect it isn't firing a resource delta). Suggestions for improvement: 1. It would be useful if the compare editor displayed what happened in each change (like it does in the single-select case). 2. If there are folders in the selection that contain deleted files, it should be possible to undelete those files from the local history.
Andre, can you take a look at my patch? This is a really useful feature and I'd like to know what needs to be done to make it real.
Thanks Stefan. I'll look at the patch after my return from vacation on 05/24.
There is currently no plan to address this item
What is wrong with the patch attached here?
Reopening to move to compare
Moving to COmpare to consider Stefan's patch.
ping
Sorry, we can look at Stefan's patch for 3.4. I missed you patch since it is actually for a different issue than what the initial bug request was for.
Mass update - removing 3.4 target. This was one of the bugs marked for investigation (and potential fixing) in 3.4 but we ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
I did look at Stefan's patch. This would be a really useful feature indeed. However, I've got some comments: In comment 10, Stefan mentioned about known issues and possible enhancement. I think the answer for most of them would be to reuse existing dialog(s) instead of using fairly ascetic ListDialog. In other words, in the UI I would reuse Local History Page and CVS History Page (with remote and mixed mode disabled) for shared resources. Given that we have this done, we would get a progress bar and comparisons for free. This would also add an option to group revisions by date which I find quite useful here. As for restoring deleted files, we could check whether there are folders selected and ask to open Restore from Local History dialogs for each of them. Two other things I would like to see here: * information which resources will (not) be restored after using the selected date/revision * an option to suggest an earliest date/change/revision which when selected will restore all of the resources An other option is to combine History Pages and Restore from Local History into one wizard. But this would be a fair amount of work.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
