On Thursday, November 23, 2017 at 11:21:52 AM UTC+1, Luke1410 wrote: > > On 22/11/2017 20:00, Stefan via TortoiseSVN-dev wrote: > > > > On Tuesday, November 21, 2017 at 11:03:11 PM UTC+1, Luke1410 wrote: >> >> Hi, >> >> talking to Julian about the TSVN UI for the new Shelve/Unshelve feature >> today, we came up with some mock-ups for that. >> >> Posting this to this mailing list to get some feedback/discussion going >> on about what you think of the concepts and where you might see some >> limitations/pitfalls. >> >> >> To initiate the (un-)shelving, you right click any folder in a working >> copy. This brings up the Shelve/Unshelve commands in the TSVN context menu. >> >> In case of hovering over Unshelve, another list pops up: >> >> [...] >> >> This list displays the (5?) most recent shelved entries which apply to >> the selected directory (i.e. doesn't contain shelve-entries which contain >> changes in paths not descendants to the current path). >> > > This might be a problem: to show those context menu entries, you would > have to do a lot of disk access to get the required info. But since the > context menu should not cause any delays (always consider slow network > shares!) disk access should be minimized as far as possible. > > Good point. I talked to Julian a bit about this. I guess I'll let him > think a bit about whether some caching behavior for that should be > integrated on the SVN side (current gut feeling is that it should), or > whether some caching-behavior would have to be added to TSVN. Or would you > argue that this would not suffice? >
Caching is always a problem, since users will expect the context menu to show immediate and real entries. And if the cache is not up-to-date, this could be a problem. Another problem which will confuse users: if you only show the last x entries in the menu, how would a user know to use the "show all" button? I'm pretty sure we will get a lot of posts on this list from users wondering where their shelves have gone... > > > >> Hovering over one of these entries displays a popup stating the >> associated comment which was entered when creating the shelved entry (see >> shelve GUI mockup below). Clicking one of these entries, will unshelve the >> entry directly (i.e. it won't bring up any detailed unshelve-dialog). >> >> Clicking on "Show all..." will display the following detailed >> unshelve-dialog. >> >> [...] >> >> This dialog allows you to perform more complex/advanced unshelve >> operations. >> > > I would just use this dialog and have only one unshelve command in the > context menu. > > In principle I'm envisioning opening up a new workflow possibility by > adding these quick-access entries. It'd only be a few clicks away to > restore work which you shelved and even easily combine multiple previously > shelved entries, something which might be cumbersome to go through via a > dialog where multiple clicks would be required to achieve the same. > Well, there's also the wait time (and some users even click) to get the submenu. Submenu: Click or wait for the submenu, click on entry, dialog shows up Maindialog: Click on entry, dialog shows up with the shelve list, doubleclick to select shelve I don't see the gain here: instead of two clicks you get a click and a doubleclick. Not really more clicks... > > > >> Checking a shelved entry via its checkbox marks this entry to be >> unshelved when clicking the OK button. >> Entries which involve changes on parent paths are by default greyed-out >> to prevent accidentally modifying files in paths outside the initially >> right clicked folder (in the previous step). Checking the setting "allow >> unshelving in different parent paths" enables these lines and allows these >> previously greyed-out shelved entries to be marked as well. >> >> Each changeset displays the changeset name (i.e. Shelved Entry 1..3), its >> associated comment, and the common parent path where the shelved entry is >> rooted from (relative to the current path - where "." means the common >> parent path is the current path). >> Note that in case of it not being the current path, the entry displays >> first the relative path based on the initially right clicked folder >> followed by the absolute path in brackets. >> >> If an entry is unshelved, it will not be removed completely. It'll rather >> end up in the trash container, so it can be restored at a later time, if >> required. Note that I didn't make a sketch up for the Trash dialog, but >> envision a simple list of shelved entries (also showing the comments) with >> a possibility to completely remove these. >> > > Will there be a timeout period after which those trashed entries get > deleted? If not, should the cleanup dialog be extended to allow cleaning of > those entries? > > Nope, the trashed entries would stay unless explicitly cleaned-up (i.e. > maybe the unshelve dialog then also should get a checkbox whether it's > removed directly or whether it's moved to trash). And yep, certainly... The > cleanup dialog should get an option to clean things up (as should the svn > cleanup command). > If it's implemented in the svn cleanup, then the cleanup dialog only needs one more checkbox and then pass the additional flag. > > >> Right clicking an entry in the unshelve-dialog brings up a context dialog >> allowing the following operations: >> >> - remove (moves the shelved entry to the trash container) >> - export (exports the shelved entry as a patch file) >> - merge (available only if selected at least 2 entries - to merge >> both shelved entries into a single entry - a popup dialog will ask for a >> name/comment of the merged shelved entry (defaulting to use the first >> shelved entry comment/name)) >> >> > How would conflicts be handled when merging two entries? > > Initially I was thinking of merging two shelved entries corresponding to > appending one shelved entry patch file to the other. But unarguably Julian > pointed out that this is quite likely to cause additional conflicts upon > unshelving these merged shelve entries lateron (while the user thought that > the merge-operation of two shelve-entries actually wouldn't cause such > problems, since this didn't trigger any warning). Given that handling this > via an alternative approach (i.e. handling conflicts at the point of > merging two entries) will be quite complex, I'd simply scrub this feature > from the proposal. > I was worried about the complexity as well, that's why I brought it up. So I'm ok with scrubbing this. > > Btw. we were thinking of whether this shelve/unshelve feature should be > shipped with TSVN 1.10 already (i.e. assuming shelve/unshelve would be > considered experimental in SVN 1.10). What's your opinion on adding an > advanced setting to TSVN's conflict dialog named: "Enable experimental > features" which by default would be disabled in the released builds but be > enabled by default in the latest dev-nightly builds? The Shelve/Unshelve > feature would then be enabled/disabled based on this setting. > > Would we really need a setting for this? I'm ok with just having this enabled unconditionally. Stefan -- You received this message because you are subscribed to the Google Groups "TortoiseSVN-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn-dev/419ff194-d133-4187-b285-5dfcb7173e7b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
