Local vs Server (phase names and clones)

[Jason Harris]

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?

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? 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.

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
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.

(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.)

Cheers,
    Jason