Rethinking mq and pbranch now we have rebase

[Matt Mackall]

On Thu, 2009-11-26 at 10:28 +0100, Peter Arrenbrecht wrote:
> On Thu, Nov 26, 2009 at 10:19 AM, Matt Mackall <mpm at selenic.com> wrote:
> > On Thu, 2009-11-26 at 09:52 +0100, Peter Arrenbrecht wrote:
> >> Folks, maybe clever use of rebase could lead to a new approach to what
> >> is currently addressed by mq and pbranch.
> >
> > You're aware that you can rebase applied mq patches and they'll continue
> > to be mq patches, right?
> 
> Yes, learning this is what started me thinking. Point is, why still
> keep the patches sitting around in .hg/patches? And (optionally)
> trying to version them as patch files? And enforcing linearity amonst
> them? When we can just keep them as csets with full fork/join support,
> and version them by just keeping rebase sources in the tree?

Well mq wasn't invented in a vacuum, it's part of a long line of tools
supporting important workflows. In some of these flows, patches (rather
than changesets) are first class objects that are maintained for
significant periods of time outside of the target project.
Backward-compatibility with quilt and rpm's linear model is also quite
useful. 

-- 
http://selenic.com : development and support for Mercurial and Linux