On 2007-07-17 22:03, Richard Lowe <[EMAIL PROTECTED]> wrote: >Danek Duvall <[EMAIL PROTECTED]> writes: >[forgot to Cc the list, sorry about you getting this twice Danek] >> On Tue, Jul 17, 2007 at 06:33:04PM -0700, mike cheng wrote: >>> Do we have a plan porting "wx backup" "wx restore" to mercurial? Or >>> Mercurial already has this feature? >>[...] >> You can also use mq for this sort of thing -- set up your patch queue with >> qinit -c, and clone the patch queue wherever you like. Though this way you >> may end up with more versioning in your backup system, depending on how >> often you run hg qcom. > > Don't use Mq with our tools. It should be safe to do (in that they'll > bail out and yell at you at the important junctures), but it isn't, to > my knowledge, being done, so there could be gaps. > > Webrev, certainly, doesn't work happily in an Mq-shaped world (where > both parent and child have patches applied, anyway)
webrev has some `interesting' interactions with merge changesets though, so it tends to be cleaner to keep a reference copy of the parent workspace without any MQ patches, and then a patch queue in a child. Rebasing the patch queue, with the instructions of the `MqMerge' wiki page of the Mercurial wiki[1], when combined with "hg qcommit" for MQ history tracking can then be a nice way to keep a local stack of patches which get rebased on top of pulls from the parent workspace. [1] http://www.selenic.com/mercurial/wiki/index.cgi/MqMerge Maybe things are cleaner and MQ would be more useful when only the child workspace uses a stack of patches ;-) _______________________________________________ tools-discuss mailing list [email protected]
