Local vs Server (phase names and clones)

[Martin Geisler]

Jason Harris <jason at jasonfharris.com> writes:

> On Jan 16, 2012, at 9:41 AM, Martin Geisler wrote:
>
>> Jason Harris <jason at jasonfharris.com> writes:
>> 
>>> The discussion on phases raised a question for me. (Again sorry if
>>> this is clear to others and I just missed it in the ongoing
>>> discussions...)
>>> 
>>> The question is in reference to local versus server in Mercurial. I
>>> gather that with secret changesets we will now be making a formal
>>> distinction between local pushing / pulling and pushing / pulling to
>>> a server. Is this correct?
>>> 
>>> I also gather then that "local" pushing / pulling would transfer
>>> private / secret changesets. But this transfer would not occur to a
>>> "server" Is this correct?
>> 
>> That's not my impression: changesets with stay-local should not be
>> transferred on push or pull.
>
> Wow! Not even on local push / pull?!? Further comments below...
>
>
>> What we discussed was transferring them on clone.
>> 
>> Today, 'hg clone foo bar' is equivalent to
>> 
>>  hg init bar
>>  hg -R bar pull -u foo
>> 
>> and it's really implemented like
>> 
>>  cp -a foo bar
>> 
>> with hardlinks between the files in .hg/store/data. If some
>> changesets wont move on 'hg pull', the equivalence between the two
>> commands breaks down and we have to decide what we value most:
>> equivalence with init+pull or performance from hard links.
>
> Ahhh... Ok. I am sure you guys have thought of this but can't you do a
> cp -a foo bar, and then strip the secret / private changesets?

That could (also) end up being expensive if you only clone a small
subset of the changesets. However, since you'll normally have a few
secret changesets and many public changesets, then stripping could
indeed pay off.

> But this raises the next question: What is the point of changesets
> which won't even be transferred back and forth locally or by a local
> clone?? How does one even work with such changesets?

With mq and rebase, for example.

> I thought the rational of secret / private changesets were things I
> could have in my repo and clones so that on a random push to some
> central server they are not transferred. But locally I can work with
> them, do history editing etc.

Yes, locally.

> In fact under http://mercurial.selenic.com/wiki/Phases the information
> on secret just states "secret changesets are changesets that are not
> visible to remote clients. This is useful to mark work private and to
> avoid inadvertently publishing changesets."
>
> But if I can't move these changes around locally then that seems
> fairly bad!

I think you promote them to draft if you want to move them.

> I very often make local clones and experiment on them. In fact I use
> experimental local clones for just this purpose of developing
> experimental "scratch/private" changesets which I don't want to widely
> push to central servers and which are still under active development
> by myself before I want to show / share them with colleagues.

That sounds like draft changesets to me.

> (This comes back to the name "secret" which I guess is fitting if we
> really can't share the changesets even locally. However, unless I am
> missing something, I just can't see the utility of such a phase. If
> local push, local pull, and local clone do actually transfer these
> changesets then I think "private" is a much better name.)

Last thing I heard is that we might go with public/draft/private and
simply don't have a short option for public changesets. The rationale is
that most changesets are public and so we don't need to refer to them
that often.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/