Sharing liquid history

Isaac Jurado diptongo at gmail.com
Sat Jan 22 19:21:06 UTC 2011


Damn, the mail didn't arrive complete.  I need to repost it :-(

On Wed, Jan 19, 2011 at 11:52 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
> First, Sorry for being a bit harsh and arrogant in the other mail. It's kind
> automatic, when anyone start talking about liquid, people get excited about all
> the cool stuff we can do with them and forget that still don't have the basic
> brick.

No problem.  I normally don't enter in design discussions because I
don't have enough knowledge of Mercurial's internals in order to make
useful contributions.  But in this particular case I had the
opportunity to explain an idea that has been hanging around my head
for some time.

>> Sorry to reply myself, but I forgot to ask how hard would it be to implement
>> liquid history with an overlay repository.
>
> The only way to gracefully handle concurrent modifications of liquid changes are
> to store a rich history of modifications made to them. The same we need vcs
> history to handle changes made to files. We need an history to handle changes made to
> changeset. The simplest way to do would be to store this liquid history into
> an overlay repository to add a nice UI to handle update and merge of concurrent
> modification.

I wasn't really meaning that.  Storing some kind of "meta-history" or
"transversal history" is something Matt is going to reject
automatically (remember the .hgtags discussions).

>From my point of view, there is a central problem with the mutating
history tools like MQ: they work directly on the repository store.  A
typical situation is when you have MQ patches applied and you pull
from somewhere else, a new head is created.  Then you wan to pop all
patches, the process would be:

   - Copy the last pulled changesets into a bundle.
   - Truncate to trim all applied patches.
   - Re-apply bundled changesets.

Truncating and reapplying changesets can be dangerous, specially since
you cannot perform the two operations atomically (I think) and with
rollback support.  Therefore, the ideal scenario would be to store
liquid changesets in completely separate, altough related, revlogs;
including the manifest and the changelog.  That is why I think the
overlay repository is an interesting implementation for this:

http://mercurial.selenic.com/wiki/OverlayRepository

This way, mangling history is no longer potentially as dangerous as it
is now because you would only be allowed to mangle liquid history, and
it would be performed in a completely separate repository so frozen
history is not touched.

This is the only thing that worries me as a future user of this liquid
extension and that's why I wanted to enter the discussion.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci



More information about the Mercurial-devel mailing list