Local vs Server (phase names and clones)

Jason Harris jason at jasonfharris.com
Mon Jan 16 20:20:08 CST 2012


On Jan 16, 2012, at 2:33 PM, Martin Geisler wrote:

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

But that's really limited.


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

But "locally" is being able to use the normal mercurial tools to work with the
changes locally on you local repositories. Local doesn't mean "isolated".


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

But I don't want to share them with others yet. See below.

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

No. That's just it. I don't want to share them with other people yet! I just
want to work on my own experimental changes myself. And in fact this is one of
the main reasons to have local clones. Ie the ability to work on experimental
features. (I am sure I can quote the hg book or other hg guides with talk of the
reasons for local clones. Eg the hg book chapter two says about local clones:
"What this means for now is that we're free to experiment with our repository,
safe in the knowledge that it's a private “sandbox” that won't affect anyone
else.") Ie local clones are the exact place we would normally play with
experimental changes we don't yet want to share with others.

I thought I would wait some time for others to comment on this but no one has
yet commented here.

Thus I just don't get it, we are going to have a phase where we can't even share
changesets locally between our own clones using the normal push / pull, clone?!?
(Not yet sure what happens to import, export, bundle, unbundle, and bundle
overlays, etc.)

This seems crazy to me unless I am missing something. When would I ever want to
use this feature to hide changesets from myself?!? (Or equivalently make it
difficult for me to move these experimental changesets around and work with
them using the normal ways Mercurial standardly allows: push / pull / clone /
import / export / overlay bundles.)

On the other hand I can see it would be very useful to be able to say: "I am
working on some experimental changesets and I don't *yet* want to share these with
others". Ie keep these changesets private to my own repositories.

The wording on the wiki page for Phases says "secret changesets are changesets
that are not visible to remote clients. This is useful to mark work private and
to avoid inadvertently publishing changesets." Pierre-Yves can you confirm that
Martin is correct here in that the secret phase is secret even from myself?  If
this is really the case then I think this is highly undesirable design...

Are people really going to heavily use this feature, and if so why? Wouldn't the
feature of "keep these changes private / local to me" be much more useful in
practice? What are the real use cases for secret-even-from-myself ?

Cheers,
   Jason



More information about the Mercurial-devel mailing list