On Thursday, 11 de November de 2010 20:51:27 Oswald Buddenhagen wrote: > > Not really. One merge is enough. > > > > > > no, it's not, because mainline will have progressed because of other > integrations. hey, wait - that's where we started from ...
[Press X]
... C1---C2---C3---C4---C5---C6---C7 [mainline]
\ \
\-F1---F2-+-M1---F3 [feature]
So the feature is done and someone requests the merging of F3. The system will
attempt to merge F3 to C7. If that succeeds, the feature is in.
If the feature introduces regressions, the requestor will have to add F4 to fix
the problems.
If the merge fails, the requestor will merge C7 to F3 (exactly what the server
tried) and fix the conflicts, creating M2. Then he submits M2 for integration.
But at that time, mainline will have progressed to C8, so a new merge is
required. Result is:
... C1---C2---C3---C4---C5---C6---C7---C8--+-X1
\ \ \ /
\-F1---F2-+-M1---F3------+-M2--
I don't call this merge spamming, it is the proper way to do things. A long-
lived branch for feature development will have many more F and M commits.
--
Thiago Macieira - thiago.macieira (AT) nokia.com
Senior Product Manager - Nokia, Qt Development Frameworks
Sandakerveien 116, NO-0402 Oslo, Norway
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
