On 23/11/2017 19:34, Stefan via TortoiseSVN-dev wrote: > > > 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. Technically the cache should be provided by core SVN which then would be ensured to always be up-to-date. So you wouldn't run into these kind of issues which we do when thinking about cached log messages and/or file statuses.
> 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... Personally I would not think so, but not having any empiric data, I'm certainly fine to drop this idea, if you think it's not that suitable/useful. So for simplicity: scrubbed for now. > > > >> >> >> 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... I'm fine with dropping this idea as mentioned above, but to clarify what I actually was thinking about: Submenu: Click or wait for submenu, click on entry, "success" dialog pops up stating the unshelving succeeded (shift+click in the previous step could correspond to not showing the success-dialog to save another click) Maindialog: Click on entry, dialog shows up with the shelve list, wait for the dialog to popup (which might be positioned on a different screen in multi-screen environments), *move the mouse to select the shelve-entry in the list*, *move the mouse to the "unshelve" button*, click the unshelve button, click away the dialog box So basically where I'd see the savings is not so much the number of clicks, but having to move the cursor to click on the actual button/entry. But as said: all fine with scrubbing this idea. > > > > >> >> [...] > > > > > 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. We are trying to push the 1.10 release now so it'll get out asap. With the shelving just having been integrated in the past weeks, it's not really considered stable and there are known caveats/missing features (most notably would be the restriction of it not working with binary data atm). Being flagged as experimental in the SVN core also means that it might break in 1.11 (even though this is currently not expected and an upgrade path would be anticipated (if the underlying format changes), though this is *not* promised!). Personally I would not consider it ready for production environments just yet, that's the rational behind hiding it behind the experimental-feature idea. Regards, 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/f7bbd408-e31c-43ba-4abc-a6a1c0c68467%40gmx.de. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
