a "patch tree" instead of a patch queue?

[Ted Pavlic]

> I'm wondering how to do something with Mercurial (or other VC software)
> that is pretty rare, possibly nonexistent. :)

How is this any different from creating branches (in any VC)?

In other words, why do you feel you need to use patches instead of 
normal changesets?

> and I can choose where I want to be along that chain. What I want is a
> tree with depth 1:
> 
>           |---> version 1
>           |
>    tip ---+---> version 2
>           |
>           |---> version 3
>           ...

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
	
IIRC, git makes this a little easier because it's possible to tag entire 
branches. That is, you can effectively say something like

	hg update -C journal.tip

That is, give me the latest version on the journal branch. I don't know 
the best way of accomplishing something similar in Mercurial.

	Something else to keep in mind is that you can use patch repos too. 
That is, you can do:

hg init -c

which creates an hg repo in .hg/patches. You could use a triple-headed 
repo *THERE* to keep track of a long string of patches.

	--Ted	


-- 
Ted Pavlic <ted at tedpavlic.com>