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? > 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? > 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. ------------------------------------------------------------------------------ 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
