Non-linear patch queues

[Sebastian Unger]

Hi Guys,

First of all, I have previously posted this to the users group but didn't
get any response and it is more a dev oriented question anyway. So I'm
reposting it here. My apologies if this violates any policy or so.

Secondly, thank you for a very cool and powerful tool. I have been using
mercurial for almost three years now, switching from SVN and I must say, I
love it. I particularly love patch queues. I have no idea how I used to do
major refactorings before PQs.

Over the last 6 months I have been using PQs very intensively as I'm going
through a major refactoring and in so doing I found that Mercurial could be
even more awesome if it had this feature:


   1. -e can be applied to qpush even when pushing patches other than the
   first. When using -a -e it is applied to all.
   2. When a patch is pushed with -e, it is applied to the node recorded as
   its parent *if *it exists in the repo or the current qtip if it isn't.
   3. When a patch is pushed without -e, it is applied on top of the
   current changeset even if it is not qtip.
   4. qtip is always the changeset corresponding to the last pushed patch.
   5. When popping, changesets are stripped from whereever they are (they
   may no longer be in a single sequence of changesets, but the qtip still
   cannot have any children according to these rules).
   6. Add a new command qlinearize (or whatever seems a suitable name) that
   for each applied patch except qbase, rebases that changeset (along with its
   children, if any) onto the previous applied patch in the series. The result
   should be a single linear sequence of changesets again.

Rationale:
I find myself quite often going up and down the patch queue and doing
refactorings in between. Once I have done a refactoring and created a
patch, I then of course find that the remaining patches in the queue do not
apply any more. So far, the easiest way I have found for dealing with this
situation is the following steps:

   - Make sure the PQ is committed (I use versioned PQs) and everything is
   pushed
   - qgo to the newly added refactoring patch
   - qfin -a
   - up -r .^
   - qpu -a
   - revert --all --mq
   - rebase -s qbase -d <node that has the refactoring>
   - qpo -a
   - strip -r 'draft()'

These steps make a lot of assumptions and are brittle (the order is
crucial). With the added feature above, mercurial would do all of that
automatically.

Let me know what you think.

BTW, I'm running Ubuntu saucy with mercurial 2.6.3. My apologies if there
is already a better way for doing this in a later version of HG.

Cheers,

-- 
*Sebastian Unger*
*Senior Software Engineer*
Tait Communications
Email: sebastian.unger at taitradio.com <sebastian.unger at taitradio.com>


www.taitradio.com

-- 

------------------------------
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140728/c06b1b71/attachment.html>