[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