A new users thoughts on mercurial queues

[Matt Rosencrantz]

I am new to mercurial and I’ve recently discovered mercurial queue’s,
which are just and awesome idea.  But I can’t help but feel like
queue’s could be more intuitively integrated.  I had a few thoughts,
which I realize are likely wrong-headed given that I’m new to all
this, but I wanted to understand why they might or might not be
wrong-headed :)  In the ideas that follow P[command] means run that
command in the patches repository.  Also, since I’m a fresh mercurial
user, please forgive my incorrect terminology.

By default the fact that the patches directory is version controlled
is not really used.  In the tutorial on how to use the queues they
never commit anything, if you do a Pstatus you’ll always see that the
files are marked as ‘A’.  I think that’s weird.

*  I feel like qcommit should really be more like
qrefresh; Pcommit [current-patch-file]
And this new qcommit should optionally take paths in the working
directory which it would behave as if passed to the embedded refresh
with -I.  Then qrefresh is something you just don’t normally use at
all, it’s only for adjusting the set of changes that belong to a patch
after the fact (if you decided to split a patch say).  This is very
natural to mercurial users (or at least seems natural to me, a new
user) who are used to running hg commit.  Now you either commit
changes to the repo, or to the current patch, either way it looks
largely the same.

* then there should be a qrollback that is actually:
Prollback; Prevert [last-commited-patch-file]
that puts the most recently commited changes back into your working
directory, in a way that is very easy to understand for users of hg
rollback, rollback gets the most recent changes back into your working
directory and out of any repo.  I would then expect hg revert -a to
get my working directory back to the state of this patch at it’s last
committed revision (plus of course all the patches applied beneath
this one on the stack).  Currently, reverting a file in the patches
repo doesn’t have the effect I expect, how can you accomplish this?:
>hg init repo
>cd repo
>hg qinit -c
>hg qnew -m "a test" test
>hg qcommit -m test1
.hgignore
series
test
committed changeset 0:92a1ae14ab1b
>echo file1 > file1.txt
>hg add file1.txt
adding file1.txt
>hg qrefresh
file1.txt
>hg status
[[as expected, there's no info here since the patch owns the file]]
>hg qcommit -m test2
test
committed changeset 1:e435e0b920c2
>hg -R.hg/patches rollback
rolling back last transaction
>hg -R .hg/patches revert --no-backup .hg/patches/test
reverting .hg/patches/test
>hg status
[[the patch doesn't own file1, it's empty, the repo doesn't own file1,
it's not committed, why is status empty?]]

note that a qrevert command would only be helpful in the rare cases
when you used qrefresh to edit the current patch without committing.

* It would be nice if there was a default patch created on qinit.  It
would just be empty and it would pick up content whenever you did
qcommit (or more unusually qrefresh).  You could rename it if you
wanted.  Whenever you delete the last patch in your patches repo
(either via qrm or qfinish) we’d just create a new default patch, so
there’s always some patch on the stack.  This would make queues look
more analogous to normal mercurial operation, you would create a repo,
start working, commit to either a patch or a repo revision, work some
more, etc.  Starting a new patch would feel more like creating a
branch.

* Couldn't each patch file in the patches repo have a header that
tracked the revision the patch applies to? (call it baserev).  Then
qpush could always trigger a 3-way merge between {baserev, baserev +
patch, working directory} (if working directory is not a decendent of
baserev, or if the patch is new and therefore has no baserev, we just
apply the patch on the working directory as best we can).  This would
eliminate the current sort-of-byzantine recommended merge dance.  It
would work for merging between patches and re-basing.  Whenever qpush
merges it should update the embedded revision in the patch file. so
after a qpush when re-basing, after resolving merge conflicts, you’d
end up doing a qcommit (or likely you would have the qpush -M
“message” option that is mentioned at the bottom of the current wiki
tutorial page).  Again this is using the modified version of qcommit I
mentioned above.  This way the best thing will happen for most users
automatically.

In all of this I'm mainly interested in using queues to solve
entangled working directory problems and building up my own patches
while frequently re-basing against some shared repository somewhere.
I know there are other cases I haven't thought about.

Anyway, I’d really appreciate any responses, like I said I’m new, and
so I suspect there are a lot of issues I don’t understand and I really
appreciate your insights.

Matt