Experimental implementation of liquid-hg

Tue Jan 18 13:01:31 CST 2011

Hi,

Call me stoneage but I would not use any kind of these features as it
is a natural flow of software evolution to improve a software and as
that happens not in the past but right now when you work on it, it is
done revision by revision.

Hence I would never go back in history to fix things in those
revisions not only because most likely things have changed and
evoluted in other directions since then.

The only thing real usecase I could think about is some kind of
extension that makes it possible to say things like "this
revision/revision set is related to the revisions: A,B,C,D and fixes
problems or improves all that is mentioned in the commit log". That
could implicitly be used as a kind of bugtracking as you create
relations between revisions that are just metadata that help to
logically understand what patches try to fix.

Greetings,
D.

2011/1/18 Pierre-Yves David <pierre-yves.david at logilab.fr>:
> What are "liquid" changeset
> ----------------------------
>
> Changeset are either *frozen* or *liquid*. *Frozen* changesets are meant to *be
> part* of the clean and canonical history and *can not be changed*. *Liquid*
> changesets can be *modified* until satisfaction, they *are not part* of the clean
> and canonical history until they are *frozen*.
>
> A *liquid* changeset can only have *liquid* descendants. A *frozen* changeset
> can only have *frozen* ancestors.
>
> Liquid changesets are useful as people usually want to refine they changes before summitting them to upstream or push them into they official repository.
>
> What I did at the moment
> ------------------------
>
> I made a *draft* implementation of a liquid changeset into an extension.
>
> The *liquid* extension add two new commands :
>
> :hg liquify <revset>:
>    Turn *frozen* changeset in <revs> into *liquid* one.  Fails if any
>    changeset frozen by this command still have *frozen* children.
>
> :hg freeze <revset>:
>    Turn *liquid* changeset in <revs> into *frozen* one.  Fails if any
>    changeset frozen by this command still have *liquid* descendant.
>
> The *liquid* extension changes the behaviour of the following commands:
>
> :hg commit:
>    New commit made as the children of a *liquid* changeset are themself *liquid*
>
> :hg push/outgoing/bundle:
>    When no explicit revision argument is provided, *liquid* changeset are
>    not included in the discovery.
>
> :hg pull:
>    When new changeset are pulled as children of *liquid* one, all they
>    *liquid* descendants are frozen to ensure consistency.
>
> The *liquid* extension add the ``liquid()`` symbol to revset. For example you can use ``hg log -r 'liquid()'`` to get the list of all *liquid* changesets. or ``hg log -r 'liquid(42:1337)'`` to get the list of liquid changeset in the 42 to 1337 revision range.
>
> The *liquid* extension is integrated with mq:
>
> * Changesets created by ``qpush`` or ``qnew`` are *liquid*.
> * Changesets imported with ``qimport -r`` are *liquefied*.
> * Changesets left by ``qfinish`` are frozen if possible (when ``qbase`` is *frozen*)
> * mq patches related to *liquid* changeset are qfinished if the at changeset freeze (by explicite call to :hg:`freeze` or automatic freeze from :hg:`pull` for example)
> * *Liquid* changeset deleted with ``strip`` or ``qpop`` doesn't confuse the liquid extension.
>
> This extensions is a *draft* a **MUST** not be used except for testing purpose.
> See the Warning section for details. In case of trouble run ``hg fixliquid`` of
> delete the ``.hg/liquid`` files.
>
> The extensions code can be found here. https://bitbucket.org/marmoute/liquid
>
> They is an experimental version of the *hgview* extension that display liquid
> changeset.  Liquid changeset are drawn squared and get a "liquid" notice in
> they description. https://bitbucket.org/marmoute/hgview-liquid
>
>
> Future evolutions
> -----------------
>
> The above interface is a *draft* and is open to discussion. I hope we can agree
> in short delay about how we want Mercurial's core commands to handle *liquid*
> changesets and what the user interface to manipulate them should look like.
>
> Once (or while) we agree about the above we must performs the two following
> action before being able to start using *liquid-hg*.
>
> * add compatibility to all cores commands compatible with liquid changesets
>
> * Add compatibility with *liquid-hg* to all extension related to history
>   editions. I'll talk more about the unification of the history editions
>   relation extension in a specific thread.
>
> When both core command and history related extensions are compatible with
> *liquid-hg*, we can forbid modification of *frozen* changesets. This is a important
> requirement for the efficient sharing and storage. Once we get *liquid-hg* usable,
> we can make it powerful.
>
> * Create simple and robust way to share liquid changeset.  We had a lot of
>  discussion about it during the sprint. I'll make a separate thread about it.
>
> * Provide efficient storage for liquid part of the history. We should be able
>  to get a specific format more flexible but less compact than revlog. dsop and
>  tonfa talked about it during the sprint. I'll let them explain their idea.
>
>
> Implementation details
> ----------------------------
>
> The ``.hg/liquid`` file stores information about liquid changeset in the forms ::
>
>    <liquid_id> <40_char_long_nod_hash>\\n
>
> a ``liquidpool`` class is handling liquid related stuff. Repo object are upgraded to the ``liquidrepo`` with a ```pool`` attribute. The liquidpool objet is meant to be **only** interface to handle liquids. It has methods:
>
> * To check if a changeset is *liquid* or *frozen* and get is "liquid id".
> * To check if a changeset can be *liquefied* of *frozen*.
> * To *liquify* or *freeze* a changeset.
> * To notify *update* or *deletion* of a liquid changeset.
>
> Extensions can also add callback for *liquify*, *freeze*, *update*, *delete*
> operation. This callback mecanisme is to be used by mq to synchronise mq file
> when other extensions alter liquid changset.
>
> The current implementation is quick and dirty. No test, few comment, no lock, no
> transaction integrity, messy message etc.
>
> TODO
> ---------------
>
> The most important task at the moment is to think about what you want *liquid
> hg* changeset  and to discuss the user interface of this draft implementation.
> The faster we can "freeze" the semantics and interface, the sooner "liquid hg"
> will flow.
>
> Technical/semantic stuff to do I have in mind are :
>
> * Add liquid support to the templater to allow commands as log, incoming,
>
> * outgoing, identify, etc to show that a changeset is liquid
>
> * Add liquid support to rollback and any other command incompatible with liquid extension.
>
> * Property lock repository during liquid operation
>
> * Ensure transaction integrity
>
> * Add verify support
>
> * Improve ui and i18n
>
> * Add liquid support to core history viewer as hgweb and hgk.
>
> * Define and add liquid support for other history editing extensions as rebase or histedit.
>
> * improve mq support to external refresh.
>
> * Add liquid support to external viewer as tortoise-hg or machg.
>
> Warning
> -------
>
> This extensions is a *draft* a **MUST** not be used except for testing purpose.
>
> * Does not lock the repository to ensure consistency.
> * Does not ensure any transaction integrity.
> * Does not support all Mercurial commands (eg: rollback is not supported).
> * Have no compatibility with history editing extensions except basic support for mq.
> * Did not received any quality testing.
> * The set of commands and they semantics are subject to change at any time.
> * The internal API will change too.
>
> In case of trouble run ``hg fixliquid`` of delete the ``.hg/liquid`` files.
>
> TLDR;
>
> Liquid is coming! Prepare you arch!
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk013hoACgkQElczi7p/bN8qOwCfb2150pz7JiO3QdZx+jDElrra
> DhYAoKBBYjgdRsfOasOhrdl7k6xbIBWy
> =esc7
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>

-- 
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C                                       #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##########################################################