Sharing liquid history

[Pierre-Yves David]

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. I would like most energy to focus on defining an implementation of local
hg.

Thanks for your interest to the liquid discussion and thank for the idea and
user point of view in you email.

On 19 janv. 2011, at 15:21, Isaac Jurado wrote: As far as my humble
> understanding of version control goes, I believe that the hardest part in
> liquid changeset synchronization is to detect relationships between them.  For
> example, you have liquid changeset A, you modify it so it becomes liquid
> changeset A'.  Therefore, there should be a way to record the fact that liquid
> changeset A is now A' in order to replace it in remote repositories (if it
> exists there).  This would be another way to take advantage of the pushkey
> feature.

The most basic solution is to use a bookmark to transmit information about
which branch of liquid changeset replace which branch of liquid changeset. This
is the way git works and would work out of the box in HG once we have liquid
changeset. However this force the use of bookmark and require some kind of
garbage collecting or dead head usage.  This solution is simple and works well
if everyone works in it's own nice and independant branch without messing up
changeset used by other people bookmark.

> Another possibility is to let liquid changesets have two IDs: the hash of the
> changeset as it first appeared and the usual hash of the changeset.
> 
> Therefore, you can detect when two liquid changesets are actually the same (but
> mutated).
> 
> Again, this has a problem.  In case you are synchronizing two liquid csets that
> have been "mutated", there is the hard decision of picking up the right one.

My experimental implementation already have a "liquid identifier" that help
different extensions to follow changes done to liquids changeset. pushkey can
use this "liquid id" to informs a repo there is a new version of a changeset
available. The new version would overwrite the old one. (with any usefull UI to
help the user to choose which one to keep and compare them).

> 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. Finding a nice UI and good algorithms to merge this liquid
history will be the tricky part :-).  Storing the liquid history into a
mercurial repository are simple but probably not optimal as you would want to
garbage collect the old part of the history you don't care about anymore.

> That's all I wanted to suggest.  I hope it makes enough sense so I didn't waste
> your time reading ;-)

You make perfectly sense, I'm looking forward for your participation into the
discussion that will emerge in a few month once we get liquid ready and
running.

Regards

--
Pierre-Yves David