Experimental implementation of liquid-hg

[Colin Caughie]

I thought I'd give some feedback on your design questions based on our corporate environment and my own development practices within it. I think this is a fantastic development, it fits in really well with our working practices (basically commit/peer-review/commit/collapse/rebase/push) and should make things a lot simpler for people who are currently afraid to use extensions like mq and histedit (but strangely have no problem with rebase and collapse).


> How to define "Public Place" ?
> ================================
[...]
>
> Public-1
> `````````
>
>     push/bundle freeze any changeset exported changeset.
>
>     Add  "--no-freeze" option to bundle/push. When this option is
> present,
>     push/bundle doesn't freeze exported changeset
>
>     Add a "no-freeze-destination" (or "private-destination") option
> in the
>     "liquids" section to store destinations that have --no-freeze
> turned on by
>     default:
>
>         [paths]
>         vm1=ssh://192.168.18.42/myproject/
>         test=ssh://selenic.com/pushtest/
>         babar=../babar-main/
>         [liquids]
>         no-freeze-destination=test, vm1, babar
>
> Public-2
> ``````````````
>
>     Liquid changeset are not include in push/bundle by default.
>
>     ("""42 liquids changeset ignored. Use "hg freeze" to freeze them
> or use the
>     --freeze option of push""" warning should be added for confused
> user)
>
>     Add a --freeze option to push? If this option is present liquid
> changeset
>     are included in the push and exported changeset are frozen.
>
>     The``hg freeze`` command allow to freeze changeset. By using
> this command
>     you say "I'll not touch this changeset again and I want it to be
> shared"
>
>     You can push changeset that are still liquid by both specify an
> explicit
>     changeset-hash/bookmark to push and use the --force option.
> Changeset
>     pushed this way are not frozen.
>
>
>     This solution is more explicit but introduce a huge change in
> behaviour for
>     standard usage of mercurial. A series of commit followed by a
> push won't
>     push those commit.
>
>
> I would prefer Public-1 as this solution doesn't introduce change in
> basic
> usage of mercurial. I also feel it more natural.

I actually much prefer Public-2. I often have a stack of mq patches, some for work in progress that I don't want to push *yet*, and some e.g. to add debugging options that I *never* want to push. When I type "hg push" I always want it to push only the patches that I've "qfinish-ed".

I can see myself using liquid in a similar way - when I push, I only want to push changesets that I've explicitly frozen. With Public-1, I would have to carefully check what liquid changesets I have before I push, and using "hg push -r" to push only the frozen ones.


> Bonus questions
> ````````````````
> (Bonus-1) how to handle pull based publish ?
>
>     I have no simple idea.

If you went with Public-2 you could handle pull in much the same way, i.e. it would only pull unfrozen changesets by default, and you could add a "--liquid" option to pull liquid ones as well.


> (Bonus-2) What to do when local frozen changeset are descendants of
> liquid changesets on the remote side ?
>
>     1) Freeze liquid ancestors of local pushed changesets.
>     2) Add local changeset as liquid descendants of the liquid
> remote.
>     3) Reject the push and require --force to push (freezing remote
> liquids).
>     4) Reject the push and require --force to push (adding
> changesets as liquids).
>
> I would reject solution 2 and 4, if you already have those liquids
> changeset
> they should have already been frozen on the remote.  I would lean
> toward (1).
> Freezing them is logic as you already have a frozen copy and adding
> more
> "reject behaviour" is frustrating from the user point of view. (2)
> is more
> explicit but less logic and more frustrating.

Sorry, I don't understand this one. An example might help?


> Are the liquid changeset I get from elsewhere "liquid" ?
> ========================================================
>
> Problem we had with pull/bundle also applies to pull/unbundle.
>
> * I unbundle a local backup of unpublished changesets:
>   -> the changegroup are liquid
>
> * I unbundle a bundle of official changesets:
>   -> the changegroup are frozen
>
> * I pull from a branch clone:
>   -> the changegroup are liquid
>
> * I pull from the official repository:
>   -> the changegroup are liquids
>
> In this example we see that we can use ``pull`` and ``unbundle`` to
> add both
> "published" and "unpublished" changesets.
>
> My conclusion is that detecting use of push/bundle does ensure that
> changeset
> are published.
>
> I can't see any sane and simple solution other than the Public-1
> approach:
>
>     pull/unbundle add "frozen" changeset by default.
>
>     Add  "--liquid" option to pull/bundle. When this option is
> present,
>     pull/bundle add "liquid" changesets.
>
>     Add a "no-freeze-source" (or "private-source") option in the
>     "liquids" section to store source that have --liquid turned on
> by
>     default:
>
>         [paths]
>         babar-featureA=../babar-featureA
>         babar-featureB=../babar-featureB
>         [liquids]
>         no-freeze-source=babar-featureA, babar-featureB
>
> Using Public-1 for pull is an argument in favor of Public-1 for
> push.

As above - with Public-2 for push, pull only pulls frozen changesets by default.

For me this would be much better than what happens now with mq: when I pull from one dev repo to another dev repo that has mq patches (which I often do to test changes on both Windows and Linux), the mq patches end up in my local repo as regular changesets, which is pretty much never what I want.


>
> Bonus questions
> ````````````````
>
> What do you do when pulled changeset apply local liquids ?
>
>     (1) make pulled changeset liquid assuming this changegroup come
> from a local backup.
>     (2) Freeze local liquids.
>     (3) Reject the pull and required either the use --liquid option
> to add then
>         as liquid or --force to freeze your local changesets
>
> (1) Is probably wrong (increase inconsistency created pull based
> publish).
> (2) Is a bit too implicit for my taste.
> (3) Is my preferred solution.

(1) suits me best, assuming the Public-2 option. It probably doesn't fit so well with Public-1.


>
>
> Are liquid changeset push by default ?
> ======================================
>
> As I already said not pushing liquid changeset by default would
> introduce a
> huge change in behaviour that we probably doesn't want. Moreover
> requiring the
> user to explicitly freeze changeset will complexity the mercurial UI
> (think
> about the git index). One of the hg strength is it's simplicity.
>
> However implicitly pushing liquid changeset will lead to premature
> publishing
> in progress changeset for people who use extension that edit they
> history. I'll
> then promote the inclusions of a "strict-local" option in the
> "liquid" section.
> If this option is set to True, liquid changeset won't be published
> by default.
> You either have to freeze them explicitly or to use the --freeze
> option of
> pull/bundle.
>
> This solution allow advanced used to choose what is to be published
> while keeping
> mercurial simple for standard user.

Actually that would pretty much address my problem with Public-1, it basically lets me choose Public-2 for my own workflow while eliminating the explicit "freeze" step for those that don't want it.

Of course the other option would be to make liquid as a whole optional; until you enable it Mercurial behaves exactly as it does now, with all changesets frozen.


> What are the ways to freeze a changeset ?
> ========================================================
>
> Do we want push/bundle(pull/unbundle) to be the only command that
> freeze
> changeset or do we introduce a "freeze" command that allow to
> explicitly mark a
> changeset as frozen ? (the freeze command better have some rollback
> support).
>
> The solution I promote for the three other questions would benefit
> from a
> ``freeze`` command. However, standard user better have to be able to
> use
> mercurial without it.

I would definitely want an explicit freeze command, even if the default behaviour was not to require it.


> ps: I'm very happy to see the liquid topic moving forward.

+1

Colin


Latest News at: http://www.indigovision.com/news2010.php