2.1 breaks my workflow (was Re: Mercurial 2.1-rc release candidate: please test!)

Matt Mackall mpm at selenic.com
Tue Jan 24 19:45:57 UTC 2012


On Tue, 2012-01-24 at 19:18 +0100, Pierre-Yves David wrote:
> On Tue, Jan 24, 2012 at 12:05:56PM -0600, Kevin Bullock wrote:
> > 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).
> 
> 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, 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.





More information about the Mercurial mailing list