On Wed, Jan 14, 2009 at 3:45 AM, Steve Borho <[email protected]> wrote: > On Tue, Jan 13, 2009 at 7:56 AM, TK Soh <[email protected]> wrote: >> >> On Mon, Jan 12, 2009 at 4:58 PM, Steve Borho <[email protected]> wrote: >> > On Mon, Jan 12, 2009 at 8:16 AM, TK Soh <[email protected]> wrote: >> >> >> >> On Mon, Jan 12, 2009 at 2:32 AM, Steve Borho <[email protected]> wrote: >> >> > Hi TK, I've heard you mention a couple of times you've done some >> >> > preliminary work on this feature. Is this available for pulling? >> >> >> >> The work need some updating due the changes tortoisehg has seen it I >> >> last worked on it. I will try update it in a couple of days and share >> >> it with the team. >> > >> > I look forward to seeing this. Let me know if you need a hand. >> >> Here's the patch queue: >> >> http://bitbucket.org/tksoh/tortoisehg-hgshelve/ >> >> Please give it a try and we can discuss it later. Do keep in mind >> right now very much a prototype with the basic support for >> shelve/unshelve. > > Finally figured out how to coax the patch queue out of bitbucket (using > download link) > Is that supposed to be done easier somehow? > > Likes: > hunk selection is very nice, well done > > Dislikes: > no way to unshelve a single file
One of the TODO is to add support to view shelved patches. We can probably the let user unshelve selected hunks there. I am also interested in avoid to display shelved hunks alongside the unshelved ones. But this can be a challenge. Plus some potential tricky corner case that need to be handled. > should it unshelve a file after it has been committed? this would be more > record-like I don't think so. Record works by shelving the changes before committing [the remaining ones], so it must unshelve after the commit. In our case, shelve is initiated by user, so unshelve should be so too. > Non-sequitors: > Does the MS column need to be visible when the working copy has one > parent? Turning is on and off will likely create more confusion. And we will need more screenshot of the same window for the documentation. > Having 'unknowns' visible at startup should be a sticky option. You risk We want to avoid making sticky option selectively. If we are going to make 'unknown' sticky, then all the other options should be too. > forgetting to add/commit new files without it. You may also miss > copies/renames. I am not sure if the risk is a valid one. An add/copy/rename/.... action is a result of an intention. If the user wants to add, then they will try look for the file in the list, and learn why it's not there. > What do you think of Qct's policy of pre-selecting files that Mercurial > would normally > commit by default (AMR)? It should be this way. In fact all FILE specified at argv should be selected. It seemed strange to have to select the files again, if I already choose to add them via, either the explorer context menu, or hgtk add. I thought Peer has volunteered to work on this quite awhile back. Maybe I'm mistaken, Peer? ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
