<br><br><div><span class="gmail_quote">On 02/03/2008, <b class="gmail_sendername">Jesse Glick</b> &lt;<a href="mailto:jesse.glick@sun.com">jesse.glick@sun.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jesse Glick wrote:<br> &gt; Probably MQ should save the original base parent for the _queue_<br> &gt; (i.e. `hg id -r qbase`) rather than an individual patch, because (1)<br> &gt; it makes no sense to save the parent of any patch which was not at<br>
 &gt; the top of the queue, (2) you might anyway reorder the queue before<br> &gt; rebasing (in which case any problems reapplying the patches is your<br> &gt; decision).<br> <br> <br>I should amend this; better to save the qbase ID for each individual<br>
 patch whenever it is created; pushed without fuzz or rejects; or<br> refreshed. You may have a &quot;stack&quot; of patches which are in fact quite<br> unrelated and which you worked on at different times, so it makes sense<br>
 to remember for each one when it was known to apply cleanly.<br> <br> MQ could include this information in the series file, e.g.<br> <br> fix-some-problem.diff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;abc123325ffb37227364298731aac<br> another-rfe.diff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 88f243ce880a7987c870987ee87d9<br>
 <br> (permitting a patch to have no specified qbase), or to retain<br> bidirectional compatibility with older versions of MQ use a different<br> file for the qbase mapping, or simply insert the information in an<br> optional patch header:<br>
 <br> # Queue base: abc123325ffb37227364298731aac<br> Description of patch.<br> diff a/file b/file<br> ....<br> <br> (&quot;Parent node ID&quot; is not an accurate description because the patch might<br> apply only atop another patch. You want to record the queue base below<br>
 all patches.)<br> <br><br> _______________________________________________<br> Mercurial mailing list<br> <a href="mailto:Mercurial@selenic.com">Mercurial@selenic.com</a><br> <a href="http://selenic.com/mailman/listinfo/mercurial">http://selenic.com/mailman/listinfo/mercurial</a><br>
 </blockquote></div><br><br>Steve Borho has an mq-repo (<a href="http://hg.borho.org/mq-tortoisehg/">http://hg.borho.org/mq-tortoisehg/</a>) that builds an
installer on top of the mercurial repository. If I want to contribute
to his mq-repo, I have to pull it AND to locate the correct repository
(in this case hg-main) and changeset to use as qbase. The latter two steps is not
automated by Mercurial today. However, I can do it with <br><br>&nbsp; hg qclone -p <a href="http://hg.borho.org/mq-tortoisehg/">http://hg.borho.org/mq-tortoisehg/</a> http:/selenic.com/repo/hg my-work<br>&nbsp; hg up -R my-work -r &lt;qbase&gt; # qbase is unknown - so just pray that it is tip<br>

<br>If the series file also stored the default path (in addition to qbase), and qclone was extended to support this, then I could simply write <br>&nbsp; hg qclone <a href="http://hg.borho.org/mq-tortoisehg/">http://hg.borho.org/mq-tortoisehg/</a> my-work<br>

and mercurial would automatically do<br>&nbsp; hg qclone -p <a href="http://hg.borho.org/mq-tortoisehg/">http://hg.borho.org/mq-tortoisehg/</a> http:/selenic.com/repo/hg my-work<br>&nbsp; hg up -R my-work -r &lt;qbase&gt; # qbase is the same as used by borho<br>


<br><br>Storing a single qbase (for the entire queue) would be fine for me. Although I do use guards, I always have the same qbase. If I wanted to have several qbases, I could make this happen using named branches in the mq-repo.<br>
<br>