phase movement notification (was RFC: Phase UI (revset, phase command and others))

Pierre-Yves David pierre-yves.david at logilab.fr
Mon Jan 2 09:59:38 CST 2012


On Mon, Jan 02, 2012 at 10:46:39AM +0100, Alain Leufroy wrote:
> On Thu, 29 Dec 2011, Matt Mackall wrote:
> 
> 
> > On Tue, 2011-12-27 at 00:11 +0100, Pierre-Yves David wrote:
> > > The user will be informed of phase movement the same way changegroup addition
> > > are notified (check last line):
> > >
> > >    % 22:31 marmoute at yamac ~/src/pylint > hg push
> > >    real URL is http://hg.logilab.org/pylint
> > >    pushing to http://hg.logilab.org/pylint
> > >    searching for changes
> > >    adding changesets
> > >    adding manifests
> > >    adding file changes
> > >    added 60 changesets with 173 changes to 314 files
> > >    90 changesets changed phases
> >
> > Bleck. I already think we're too chatty here (especially with progress
> > enabled). And I generally don't want users who are not using phases
> > (because they're using rebase or mq today) to have to know or care about
> > them at all. If an existing user upgrades they shouldn't have to think
> > "wait what?? what is a phase? omg this dvcs crap is so complicated!"

+1 for not confusing Basic user.[1]

-1 for verbose being the only way to have this information.

People actively playing with phases need to know when they move. If half of
their currently draft changeset becomes immutable they need to know it quickly.
If a faulty push set multiple stuff as public on remote when it wasn't intended
they need to be informed too. Discovery such movement later does not seems a
valide option to me. We must have a way to turn such notification on all the
time for people who care. I see two options :

A) Display such notification when remote or local if publish==False.

    People exchanging changeset with non-publishing remote  are  most probably
    already aware of phase and can use the data.

    People having working repo non-publishing are most certainly aware of them.

    The drawback of this approach is that publish=False alter client's behavior
    (display wise).

B) Having a dedicated option for always displaying such data:

    This prevent publish=False to mess with public repository but this option
    will probably always set to True for advanced people who will set publish
    to False too.

> hum, however this information is interesting...
> Note that for those users the message will be::
> 
>   added 60 changesets with 173 changes to 314 file
>   60 changesets changed phases
> 
> So, to prevent confusion this line may be omitted if all added changesets are
> changed to "publish".
> And/or the message may be 'published 60 changesets'.

The idea is interresting.


For people using a basic worflow where everybody push and pull to a central
server nothing would print:

    hg pushing N changesets will always make exactly those N changesets public
    without common but draft ancestor.

    hg pulling N new changesets will always pull them as public and they will
    never have draft ancestor.

For people who use pull heavy workflow, phases related print will appear to
inform the user than some local changeset are now available elsewhere.

    1) B pull X,Y,Z from A (3 changeset pulled as public, left draft on server)
        no phase print
    2) A pull from B (nothing found but 3 draft changeset mark as public)
        phase print about the three changeset now available elsewhere.


This idea does not prevent the need of a "alway display phase data" mode. If I
pull 5 new changesets based on a public root advanced user will be want to know if
those changeset are added as public or as draft.


-- 
Pierre-Yves David

http://www.logilab.fr/

[1] Start simple, add complexity when you need more feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120102/e5de8830/attachment.pgp>


More information about the Mercurial-devel mailing list