LiquidHg via MQ

[Kevin Bullock]

On May 2, 2011, at 7:56 PM, Arne Babenhauserheide wrote:

> This might be a naive question, but could LiquidHg be implemented as an 
> interface to versioned MQ? 

That's sort of backwards to the point of LiquidHg; it's meant to provide a unified way for all the history-editing mechanisms to be able to work safely. Thus MQ should (eventually) be built on top of LiquidHg, not the other way round.

> PS: Is it really necessary to add garbage collection when using bookmarks? 
> That violates the principle that no work gets lost without explicit action by 
> replicating a (mis-)feature of git.

That doesn't seem to be a part of the current thinking (and I hope the idea has actually died, because it would basically kill the simple workflow).

> PPS: I don’t completely understand the deathset². Is it an alternative to 
> garbage collecting unreferenced revs?

This must come out of Martin's work on the idea of "dead heads". Basically, a way to mark a line of development that is no longer being pursued and that shouldn't be propagated to new clones. The changesets remain in existing clones and can be _manually_ pulled into new ones.

> Also I’m not clear about the definiton of 
> frozen changesets²: Does it mean that a frozen changeset can’t be liquefied, 
> even if I never pushed it anywhere? So that anyone who wants to use liquid can 
> only enjoy its benefits on new changesets but not on old (but not yet pushed) 
> ones?

Nope, the notes say pretty clearly that with some manual intervention, you'll be able to liquefy existing changesets. That's pretty much morally equivalent to history editing, though.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock