Experimental implementation of liquid-hg
Isaac Jurado
diptongo at gmail.com
Wed Jan 19 14:21:37 UTC 2011
On Wed, Jan 19, 2011 at 2:22 PM, Martin Geisler <mg at aragost.com> wrote:
> Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
>
>>> And this is similarly not quite right. It's the act of pushing a
>>> changeset to a public repo that should freeze it. Changesets that are
>>> local only should remain liquid indefinitely.
>>
>> I think we mostly agree on the goal of liquid changeset. In order to
>> not change too much stuff at the same time I was a bit shy for the
>> semantic of this experimental implementation. As we seems to share
>> most vision on liquid. I'll propose a more ambitious semantic.
>>
>> I think we agree on the two following statements.
>>
>> (1) You *CAN NOT* use any history editing commands on "Frozen"
>> changeset. (You shall only edit *liquid* changeset)
>>
>> (2) Any changeset you published *MUST* be frozen. (Liquid
>> changeset are meant to be local only)
>
> I don't really agree with this -- if I cannot publish liquid changesets,
> then there is no fun to all of this.
Indeed. But I also agree with Matt/Linus in that rebasing is not
something you want to do with already pushed history.
I remember talking about this Liquid thing on IRC and I had the
impression that the purpose is something like having mutable history
(i.e. liquid) and immutable history (i.e. frozen), where you could
transfer or synchronize both. In other words, like MQ on steroids.
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.
However, with this approach the changeset transformation chains may
grow substantually (due to misuse, for example) and we would end up
having some kind of "transversal" history. 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.
That's all I wanted to suggest. I hope it makes enough sense so I
didn't waste your time reading ;-)
Cheers.
--
Isaac Jurado
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
More information about the Mercurial-devel
mailing list