Some initial impressions of phases
Pierre-Yves David
pierre-yves.david at logilab.fr
Tue Jan 24 06:49:44 CST 2012
On Tue, Jan 24, 2012 at 12:48:55PM +0100, Jason Harris wrote:
>
> On Jan 24, 2012, at 12:22 PM, Pierre-Yves David wrote:
> > On Tue, Jan 24, 2012 at 10:57:16AM +0100, Martin Geisler wrote:
> >> Jason Harris <jason at jasonfharris.com> writes:
> >>> On Jan 23, 2012, at 11:03 PM, Matt Mackall wrote:
> >>>>> Jason Harris <jason at jasonfharris.com> writes:
> >>>>>
> >>>>> Point 11.
> >>>>>
> >>>>> A local clone resets the phase to public. It shouldn't.
> >>>>
> >>>> Debated elsewhere, many arguments pro and against exist.
> >>>
> >>> Well, I believe it's going to cause problems in practice. Local clones
> >>> for experimentation are going to be hampered with having to manually
> >>> adjust the phase for each clone.
> >>
> >> It was my understanding from the beginning that draft changesets are
> >> meant to be shared and that they were meant to be shared *as draft*.
> >> This is why I think they should remain drafts when you clone. Public
> >> servers can set publishing=True so that everything pushed there becomes
> >> public.
> >
> > We already have a well defined concept to say "I wan't draft to stay draft":
> >
> > http://selenic.com/hg/rev/218ec96c45d7
>
> Sorry maybe I missed it in reading that, but you meant "I want draft to stay draft" right?
> If so how do I do this?
yes s/wan't/want/
> Do you mean that if I set
> [phases]
> publish = 0
>
> or publish =1, or publish = 2 in my hgrc then a local clone is meant to preserve the phase?
> If so this doesn't happen.
You read it wrong: You setting up a non-publishing repo using.
[phases]
publish=False
> Point 12:
> Note of course we should use private, draft, public, instead of 0, 1, 2.
But we use "true" and "false" (and other synonyms)
> Point 13:
> BTW for the documentation there is no help in the hgrc about phase.
> Eg 'hg help hgrc' doesn't mention anything about phase settings.
breaking news: Phase documentation is still a stumb and something to be heavily
working on during the freeze. Any help is welcome on this side.
> > (And We have valid reason not to turn it on by default)
> >
> > We don't have any way now to detect a branch clone is intended to be private to
> > the dev only.
> >
> > I'll keep recommand the existing, simple and well defined way to have the
> > expected behavior. I probably won't change my mind[1] until someone came with a
> > meaninful proposal on this matter and a simple alteration of clone behavior.
>
> It might be simple, but it's highly highly inconvenient for working with clones.
> This is really a case where we should separate what is easy to for implementation
> and what works well for users.
>
> At least there needs to be *some* way to get the behavior that most users will find
> the most useful.
There is a way. Setting your development repositories as "private" (not public,
not publishing). This is simple and *available in 2.1* way to do that.
> Also I gave the meaningful proposal of allowing configuration in the hgrc like:
(1) This proposal does not cover detecting a private branch clone.
(2) This proposal will not be in 2.1 and I do not think the freeze is the right
time to discuss hypothetical proposal like this one.
note: As said before, this proposal looks interesting (but out of topic and timing).
> Even if it's not the default there needs to be some way to do this. (Once there is
> we can argue about what the default should be :) )
Again. There *is* already a way. And there is already arguing on this topic.
Look at the commit description again.
--
Pierre-Yves David
http://www.logilab.fr/
-------------- 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/20120124/630db74c/attachment.pgp>
More information about the Mercurial-devel
mailing list