Mercurial 2.1-rc release candidate: please test!

[Matt Mackall]

I've just tagged and uploaded the tarball for Mercurial 2.1-rc, which
we'd like help testing.

The biggest feature here is stage 1 of support for 'phases', a scheme
that allows Mercurial to automatically track which changesets are
published and thus allow you to safely rebase and modify local history.

If you're already using mq or rebase today, this should 'just work':
you'll be allowed to freely rewrite changesets that are 'draft', but
you'll have to manually force changes on 'public' (already pushed).

Other notable features include improved support for working with remote
branches and a remote() predicate for revsets. For example:

hg diff -r "remote()"

..will lookup the head of your local branch on your default server, and
if it's present locally, generate a diff of all your local changes.

--
Mathematics is the supreme nostalgia of our time.

_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[L. David Baron]

On Friday 2012-01-20 16:17 -0600, Matt Mackall wrote:
> I've just tagged and uploaded the tarball for Mercurial 2.1-rc, which
> we'd like help testing.
>
> The biggest feature here is stage 1 of support for 'phases', a scheme
> that allows Mercurial to automatically track which changesets are
> published and thus allow you to safely rebase and modify local history.
>
> If you're already using mq or rebase today, this should 'just work':
> you'll be allowed to freely rewrite changesets that are 'draft', but
> you'll have to manually force changes on 'public' (already pushed).

So it turns out this breaks my primary development workflow.

I use mq for all of my development work on Mozilla. I frequently
want to test what I'm working on on multiple machines (different
platforms). Additionally, on my primary development platform
(Linux), I do most of my actual work on a laptop, but I do
compilation on a more powerful desktop using the same setup.

The way I've been doing this is to pull from a tree with mq patches
applied into other "throwaway" trees, from which I:
hg pull && hg up -c && make ...target...

This has two big advantages over other workflows:
(1) it's a lot faster than sharing queue repositories and pushing
them to the same state in different places

(2) It touches only the files that were modified, unlike pushing
and popping queues, which means I get the advantages of depend
builds (which, for a large project like Mozilla, is a big deal).
(I do all the qpop and qpush operations in the tree on my laptop,
which I don't build from.)

It seems that in 2.1, "hg serve" no longer serves changesets managed
by mq (and "hg help serve" doesn't show any way around this).

So I tried 2.1-rc, and now I've reverted back to 2.0.1.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Kevin Bullock]

On Jan 23, 2012, at 4:40 PM, L. David Baron wrote:

On Friday 2012-01-20 16:17 -0600, Matt Mackall wrote:

I've just tagged and uploaded the tarball for Mercurial 2.1-rc, which

we'd like help testing.

The biggest feature here is stage 1 of support for 'phases', a scheme

that allows Mercurial to automatically track which changesets are

published and thus allow you to safely rebase and modify local history.

If you're already using mq or rebase today, this should 'just work':

you'll be allowed to freely rewrite changesets that are 'draft', but

you'll have to manually force changes on 'public' (already pushed).

So it turns out this breaks my primary development workflow.

I use mq for all of my development work on Mozilla.  I frequently
want to test what I'm working on on multiple machines (different
platforms).  Additionally, on my primary development platform
(Linux), I do most of my actual work on a laptop, but I do
compilation on a more powerful desktop using the same setup.

The way I've been doing this is to pull from a tree with mq patches
applied into other "throwaway" trees, from which I:

 hg pull && hg up -c && make ...target…

1. If it's pulling into a throwaway tree, could you reverse it and push instead? If these are local repos relative to each other, this is trivial and a push --force might do it (though I'm not sure this has actually been implemented yet).

2. Does it work if you apply the patches and then manually set the MQ change sets to draft?

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和

Kevin R. Bullock

[Pierre-Yves David]

hg push --force do not push secret changeset(and never will push secret changeset as far I'm concerned)

> 2. Does it work if you apply the patches and then manually set the MQ change sets to draft?

Setting mq patches to draft will work.

But there is no way to tell mq to not handling it's content as secret. so it'll
keep turing sturning stuff secret from time to time.

3. consider using bundle to transmit your changeset

--
Pierre-Yves David

http://www.logilab.fr/

[L. David Baron]

On Tuesday 2012-01-24 12:05 -0600, Kevin Bullock wrote:
> 1. If it's pulling into a throwaway tree, could you reverse it and
> push instead?

That's much more complicated mentally (and in some cases also in
terms of network permissions), since the changes are coming from a
single repository but going to many different ones. So pull in the
target is always the right thing, but if I wanted to use push I'd
need to think about which machine and which tree on that machine I'm
pushing to, and make sure the network actually let me do that.

> 2. Does it work if you apply the patches and then manually set the
> MQ change sets to draft?

You mean with a command like "hg phase -r'mq()' --draft" ?

I'd like to note that we're talking about an operation that sits in
the middle of my code-compile-test cycle, and currently takes a few
seconds.

I'd really just like an option (either for mq or for serve) that
lets me keep doing what I've been doing, without having to type
extra commands each time.

[Matt Mackall]

Pierre-Yves, please note that David has invoked the magic words:

"breaks my workflow"

..which is of course the primary measure of whether something is failing
in being backward-compatible.

We will have to make mq go back to draft by default unless
non-breaks-my-workflow alternatives are suggested.

--
Mathematics is the supreme nostalgia of our time.