[informatique] Re: a "patch tree" instead of a patch queue?

Ted Pavlic ted at tedpavlic.com
Thu May 29 13:06:17 UTC 2008


>> hg qpop -a
>> hg qguard arxiv +arxiv
>> hg qguard journal +jounal
>> hg qselect arxiv
>> hg qpush -a
> I played with this idea today and got it to work the way I want --
> mostly. :)  It does effectively do what I asked about in the original
> post, but Ted's suggestion of multiple heads (possibly in the patch
> queue repo) got me thinking and I might try something different. For
> example, it's common to upload several updated versions of a paper to
> the arxiv. With this setup, there's no history of the state of my
> document when I uploaded it -- I can't use tags to revert to the exact
> version I uploaded previously. Version controlling the patch repo might
> do this. 

Keep in mind that you can have multiple patches that are guarded. That 
is, you can have a patch stack:

preprint1 -> preprint2 -> preprint3 -> journal1 -> journal2 -> journal3

and you can guard all of the preprints one way and all of the journals 
the other. Then you have some history of changes.

I'm GUESSING that the "best" solution is probably to either:

*) Clone your repo into a base, preprint, and journal repos, and then 
merge changesets from your base repo into the preprint and journal repos

OR

*) Create a two-headed repo. Use "hg branch" on each branch so that you 
can easily get to the tip of each branch. Then make modifications to the 
journal and preprint branches as needed. If you need to make base 
changes, go back to the fork between the two branches, make a 
modification, and then merge that changeset into the two branches.

--Ted


-- 
Ted Pavlic <ted at tedpavlic.com>



More information about the Mercurial mailing list