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