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.
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,
not the changes left in the working directory.
Maybe it's a subtle difference, but I think it will be initially confusing
to many. That's why at least the button names should be changed between the
two modes.
--
Steve
------------------------------------------------------------------------------
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
