Mozilla project choses Mercurial

[L. David Baron]

On Wednesday 2007-05-16 23:07 -0400, Daniel Holth wrote:
> solo turn wrote:

(I'm curious where; I didn't see the start of this thread.)

> > except http://dbaron.org/log/2007-04#e20070417a  (which basically says
> > common operations require way too many steps).

> Perhaps he wants:
> 
> a -> b -> c
> b -> d
> b -> e
> ...
> b -> z

Well, really, I want something slightly more complicated, since some
of my changes will be inherently stacked, so in such cases I'd want
to maintain a branch off of a branch (such that the tip of the
second branch always has the tip of the first branch as an
ancestor).

> So I merge changes c-z together to build my integration branch. Let's
> say they all touch different files so we don't need to use a merge

For what I do, that's pretty unrealistic.  Even excluding the
stacked patches, I'm touching the same files, and often the same
code, with reasonable frequency.  (I'd say I have to do hand-merging
of .rej files as a result of reordering the patches in my own mq
series more than once a week.)

So when I pull changes from upstream, I'd need to merge every branch
so that each branch's tip has the upstream tip as an ancestor.  And
then I'd need to either recreate the integration branch, or merge
all the new branch tips onto it.


That said, I haven't tried any of this.  I'm currently at an
intermediate stage where I'm still using mq, but with the
two-working-trees solution that I mentioned, so that I don't have to
touch the timestamps in the tree I build with as much.  (Although
there is a bit of unnecessary updating of timestamps across an
update that doesn't modify a file, but only when multiple changes
affecting that file were reordered.)

The idea of maintaining an integration branch integrating 20 or so
changes (and merging all of those changes separately every time I
update) seems too daunting.  I've learned to live with "while hg
qpush && hg qrefresh -s; do true ;done".  And mq has the advantage
that I don't lose track of patches.

-David

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20070516/a73fbcd6/attachment-0001.asc>