Experimental implementation of liquid-hg

Martin Geisler mg at aragost.com
Wed Jan 19 07:22:05 CST 2011


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. It seems that your proposal sort of
boils down to doing 'hg outgoing' against all known paths and only
allowing people to edit changesets not yet pushed.

I think it is very interesting to

a) maintain information about what is liquid and what is not

b) use that to prevent accidental manipulation of frozen changesets

c) implement mechanisms that allow me to push changes to liquid
   changesets

It is the last point that I'm actually interested in -- it is that point
that adds more power to the system than what we have today.

You will say that it's important to protect users, but that is why I
asked if you see many questions about bad rebases? I don't see these
questions in the support forums we have -- I tried searching the
mailinglist, but didn't find anything.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/


More information about the Mercurial-devel mailing list