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.
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.
If an MQ patch is applied, then the commit dialog should perform a qrefresh
rather than a commit.
>From a separate menu option, perhaps "Status", perhaps some new menu option
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.
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.
--
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
