a "patch tree" instead of a patch queue?

[Ted Pavlic]

Before I add these comments, I just want to stress the idea of using a 
patch *repository* (initialized with "hg qinit -c" instead of "hg 
qinit"), which might solve all of your problems without much extra work.

If your *PATCH* repository was triple headed, you still would be able to 
  pop off all patches and modify your base document, but then you could 
choose when patch to push back on by choosing which head of the patch 
repository to use. You could make aliases in your .hgrc to make the 
commands simple to use.

>> In other words, why do you feel you need to use patches instead of 
>> normal changesets?
> 
> One reason is that I seem to make "shotgun commits": I make a commit,
> then, over the course of the next 15 minutes, make a bunch of tiny
> commits adding in tiny bits I've forgotten and fixing dumb mistakes.
> With a patch queue, I just keep doing 'qrefresh' and it gathers up all
> my work for me.

Keep in mind that if you're only using qrefresh (and not qnew), you're 
not really using a patch QUEUE. Instead, you're using a SINGLE PATCH. 
That is, you're discarding your previous changes each time.

If you had a three headed repo, you'd replace your frequent "qrefresh" 
with "commit", and otherwise things would be very similar. Note that you 
can use "qimport" to convert a changeset to a patch. That lets you 
"change history."

It's true that you'd have trouble if you wanted to modify the base 
revision of your article. Of course, if you had multiple patches 
relative to that base, there's a good chance that your patches would 
FAIL after significant modifications to the base. So, you'd have to 
repair your patch files manually. Which is more trouble?


Finally, as I mentioned before, I'm pretty sure that **git** has better 
support for this than Mercurial. That is, git effectively lets you name 
(i.e., "tag") an entire branch (rather than the changeset at its root). 
Then you can quickly jump to the most recent changeset in that branch.

That being said, it's not too difficult to do an

	hg heads

to see the three changesets at the tip of each of your branches. Then 
you can use

	hg update -C 56

where "56" is the short revision number corresponding to the changeset 
you want to switch to.


> I also mentioned patch queues because they're pretty lightweight,
> flexible, and I understand them.

MQ is not meant to replace hg. Both vanilla Mercurial and MQ should be 
viewed as pieces of a bigger picture. Using only one can be cumbersome 
and/or dangerous, especially when repositories become distributed. Just 
be careful, and have faith that taking the time to learn a little bit 
more about (vanilla) hg can be a worthwhile investment.

>> Why can't you just create two three branches so that your repo becomes 
>> triple headed? For example...
>>
>> 	# Tag the root to find it later
>> 	hg tag root
>>
>> 	# Commit changes you've made to journal version
>> 	hg commit -m "Journal version"
>> 	hg tag journal
>>
>> 	# Go back to root version
>> 	hg update -C root
>>
>> 	# Commit changes you made to preprint version
>> 	hg commit -m "Preprint version"
>> 	hg tag preprint
>>
>> 	# Go back to journal version
>> 	hg update -C journal
> 
> I often get confused when I read things about branching and tagging and
> so on, but I will look at this.

At least in Mercurial, the terminology is pretty self-explanatory (but 
it's easy to overthink things). A "branch" is just a fork in your 
repository's history. A "tag" is just a convenient name for a revision. 
If I have to frequently go back to a particular revision, I'll tag it 
for easy access later -- that way I don't have to remember its changeset 
ID (each revision has a unique changeset ID).

Check out the Mercurial tutorial and quick start. You might enjoy 
Mercurial a little bit more if you see the basic usage.

> Looking through the list archives (why didn't I do that before?) I see
> that this concept comes up rather frequently. The "Managing independent
> queues" thread from last month mentioned multiple patch queues, which is
> basically what I was thinking. But having multiple heads might work just
> as well for my needs.

A single repository may have both multiple heads and multiple queues, 
where each queue has multiple patches and possibly even multiple heads. 
These things are not mutually exclusive; they're all part of a bigger 
picture.

--Ted


-- 
Ted Pavlic <ted at tedpavlic.com>