On Thu, Jan 15, 2009 at 6:09 AM, Steve Borho <[email protected]> wrote: > On Wed, Jan 14, 2009 at 11:05 PM, TK Soh <[email protected]> wrote: >> >> On Thu, Jan 15, 2009 at 2:44 AM, Steve Borho <[email protected]> wrote: >> > On Wed, Jan 14, 2009 at 5:57 PM, TK Soh <[email protected]> wrote: >> >> >> >> On Wed, Jan 14, 2009 at 8:43 PM, Steve Borho <[email protected]> wrote: >> >> > On Wed, Jan 14, 2009 at 8:13 AM, Steve Borho <[email protected]> wrote: >> >> >> >> >> >> On Tue, Jan 13, 2009 at 11:27 PM, Abdul Halim <[email protected]> >> >> >> wrote: >> >> >>> >> >> >>> Neh.. It is not the habit.. It is the environment. Especially, when >> >> >>> the >> >> >>> customer >> >> >>> is beside you breathing down your neck. Guess I have to stick to >> >> >>> Qct >> >> >>> then. >> >> >> >> >> >> My view is that when you're in the commit window, you're expecting >> >> >> record >> >> >> type functionality. When you're in the status window, you're >> >> >> expecting >> >> >> shelve type functionality. >> >> >> Does that make any sense? >> >> > >> >> > Let me expand on this for a bit. First, a refresher for everyone who >> >> > is >> >> > new >> >> > to these types of features: >> >> > >> >> > There is the record.py extension, written by Bryan O'Sullivan, based >> >> > on >> >> > the >> >> > darcs command. You run 'hg record' instead of 'hg commit'. It >> >> > iterates >> >> > through all the modified files and interactively allows you to select >> >> > changes to be included in the commit. It then does the physical >> >> > commit, >> >> > then leaves the remaining changes in your working directory (for the >> >> > next >> >> > commit, etc). This extension also adds a 'qrecord' command that is >> >> > used >> >> > just like 'hg qnew' except that again it allows you to select the >> >> > changes to >> >> > include in the new patch. >> >> > >> >> > There is the mq.py extension, written by many, which allows you to >> >> > manage a >> >> > stack (queue) of patches that can be pushed and popped to your >> >> > repository as >> >> > changesets. >> >> > >> >> > Then there is the hgshelve extension, written by TK, based on the bzr >> >> > shelve >> >> > command. It allows you to take individual changes that are in your >> >> > working >> >> > copy and remove them to a safe place, temporarily, until you unshelve >> >> > them. >> >> > The shelved changes are stored as a single patch file under >> >> > .hg/shelve. >> >> > In >> >> > essence, if you think about it, the shelf is an unnamed MQ patch that >> >> > is >> >> > never converted into a changeset. You could do the same thing with >> >> > hg >> >> > qrecord shelve ; hg qpop -f. >> >> > >> >> > Qct supports change selection for commit in a manner very similar to >> >> > the >> >> > record extension, in that you selected those bits that were to be >> >> > committed, >> >> > did the commit, then the remaining changes were added back to your >> >> > working >> >> > copy. Both Qct and record.py accomplish this by copying your working >> >> > copy >> >> > file into a backup location, reverting it to it's last revisioned >> >> > state, >> >> > then selectively applying changes back to the reverted copy. After >> >> > the >> >> > commit, the original file is recovered from backup (making the round >> >> > trip >> >> > always safe). >> >> > >> >> > With MQ and shelve, you are storing patches under .hg/ and thus when >> >> > you >> >> > go >> >> > to reapply them you may get conflicts if the original files have been >> >> > modified too much. >> >> >> >> Very good summary :-) >> >> >> >> OT: You should consider posting it on Mercurial wiki. I'm sure they >> >> are Mercurial users who are not very clear on how these extension work >> >> [together]. >> >> >> >> > I think the change selection UI TK has added to the status/commit >> >> > dialog >> >> > can >> >> > allow us to support all three of those work-flows (record, shelve, >> >> > MQ). >> >> > It's just a question of how to present the functionality to the user. >> >> > >> >> > My theory is that when the user launches the commit window, they are >> >> > interested in checking in code. Thus the change selection features >> >> > should >> >> > be used in a record like manner. The shelve button should be renamed >> >> > to >> >> > something that implies "Do not commit", and the unshelve button >> >> > should >> >> > be >> >> > hidden. The working copy files shouldn't be modified until the >> >> > commit >> >> > button is pressed, and after the commit they should be restored. >> >> >> >> It's not clear to me here. Are you talking specifically about the >> >> commit window, and the status window would have a different set of >> >> interface? Why does the unshelve button be hidden? >> > >> > Commit is/would-be a different dialog from the one that is used to >> > shelve >> > changes to a patch file. Perhaps the unshelve button should be left in >> > place, but it would need to reset the change selection, which is not >> > quite >> > an un-shelve. >> > >> >> >> >> > If an MQ patch is applied, then the commit dialog should perform a >> >> > qrefresh >> >> > rather than a commit. >> >> >> >> This seems reasonable. >> >> >> >> > From a separate menu option, perhaps "Status", perhaps some new menu >> >> > option >> >> >> >> Which menu? >> > >> > The explorer context menu. >> > >> >> >> >> > called 'Shelve' or 'Patch', we open up the status dialog and again >> >> > allow >> >> > the >> >> > user to select changes. In this mode, however, the changes are >> >> > either >> >> > stored in an unnamed "shelve", or we allow the user to give a name to >> >> > the >> >> > file, in which case it gets added to .hg/patches. >> >> > >> >> > The changeset dialog can be used to display shelve/patch contents. >> >> > At >> >> > this >> >> > point, we're 30% of the way to supporting MQ outright. >> >> >> >> Cool. >> >> >> >> > This idea needs more work to keep it from being confusing to users. >> >> > In >> >> > one >> >> > case your selecting chunks to leave out of a commit and in the other >> >> > case >> >> > your selecting chunks to add to a patch. >> >> >> >> I'm not very clear what you're trying to say here. >> > >> > When operating in 'record' mode, the changes you select are removed from >> > the >> > working copy just for the commit, so the end result that you are >> > building is >> > the contents of the commit... what's left showing in the commit dialog. >> >> This feels potentially confusing. My original thought is we should >> commit the _selected_ chunks, not the other way round. This is also >> consistent with the behavior of the Record extension, i.e. pick the >> diff hunks to be recorded. >> >> Instead of trying to 'stack' the record function on top on the shelve >> function, maybe we should just separate them. That is, the 'Shelve' >> button shelve the selected hunks, while 'Commit' button commit the >> selected hunks. >> >> I know it will probably need a lot more work, but it's clearer this way. > > I think your idea is on the right track. If all hunks were selected by > default when > a file was selected, it would work better. That's an easy change, though.
Great! > One thing we lose this way is the ability to test the selected changes being > committed > before actually committing them, like you could with Qct (you could build > and run the > working directory while Qct was up). Though I guess a user could shelve > the changes > they want to withhold, build/test/commit, then unshelve. I believe that's generally what the shelve extension for. > We should have a button to reverse the hunk selection for selected files. > > I think I could build a prototype for this tomorrow. We should get some > user-feedback > on how it feels. > >> > When operating in 'shelve/patch' mode, the changes you select are moved >> > into >> > a patch file, and it's this patch file that is the primary >> > consideration, >> >> you mean primary consideration for commit? > > I was speaking of a new dialog that would look just like the status dialog, > only it would > support shelve/MQ operations. But now I'm thinking we should just fold it > into the > commit dialog as you suggest. ------------------------------------------------------------------------------ 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
