On Feb 4, 2010, at 7:42 AM, Markus Roberts wrote:
Our idea is to have the topic branches be rebased in succession onto
testing (which is a mercurial/throwaway branch), producing a clean
series of commits that can be tested and the prefix of which can be
promoted to master once it is deemed worthy.
Are there any examples of what you're planning to do up somewhere
Markus?
We've recently moved all the Debian packaging to use git-buildpackage
(which is brilliant), but relies heavily upon being able to merge,
and
I'm not quite clear from your descriptions above whether we'd still
be
able to do this.
I don't think that should be affected--hedged, because this is all
speculative at the moment--as I'm only concerned here with the process
of funneling long-lived topic branches (agressive bug fixes, new
features, extensive refactorings) through testing and into master.
The basic idea is this:
* We have in the queue a bunch of modifications that make sweeping
changes to the system (architectural changes, internal data path
refactorings, global renamings, code smell reductions, etc.).
* They form a forest of dependencies, with some subsets having
structured relationships (it makes no sense to do H without F and G,
and J is an alternative implementation of H) and others being
completely orthogonal.
* Many of them touch intersecting sets of lines
* None of them have been extensively tested
* We'd like to start putting these together into a coherent,
testable build
* We'd like to reserve the right to remove / reorder / rework parts
and try again
* We don't want the resulting change history to look like a bowl of
noodles
So:
* We are writing a rake task to take a list of branches and a set of
sanctioned resolutions for potential conflicts and build a mercurial
testing branch on top of master which applies these changes in a
controlled, coherent order.
* The branch should be creatable by anyone who wants to play with it,
and then thrown out when they've seen what they came to see
* At any time that some prefix of this branch is deemed sound it can
be applied to master as a fast-forward and removed from the list of
testing branches (though the results should be roughly the same even
if it is not removed).
* My present inclination is that this testing branch should be
constructed as a single linear branch from master, with no merge
commits either created in the process or absorbed from the component
branches
* There may be extensive rebasing, squashing, cherry-picking,
amending, reordering and other shenanigans going on in the testing
cycle
* Once things actually make it to master it should be business as
usual, with no rewriting of history or playing games with the space
time continuum.
Just to follow-on, this is pretty much exactly what I was hoping for.
I'm not totally sold on skipping merge commits. While I get that
they're not well-supported in the git tools, they can make some
aspects of life much easier.
I was actually thinking it might make sense to require merge commits
in the testing branch, just so you can easily track exactly what was
merged and in what order.
--
It's very hard to predict things . . . Especially the future.
-- Prof. Charles Kelemen, Swarthmore CS Dept.
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
