Question about Source Control

[Terry Reedy]

On 3/23/2014 10:04 PM, Chris Angelico wrote:
> On Mon, Mar 24, 2014 at 12:26 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> With multiple branches (as with 2.7, 3.4, and default for cpython) and
>> multiple active developers (20?) commiting to those brances, commits are
>> definitely not free. I would not exactly call them as cheap as you seem to
>> imply either. That said, I have occasionally pushed interim changes that put
>> code in an improved and stable state.
>>
>> N. Coughlan has suggested improving the cpython infrastructure and
>> procedures to reduce the cost of commits to encourage more people to make
>> more commits (in the sense of more lines changed, not more pieces) and
>> improve cpython faster.
>
> When I call them cheap, what I mean is that there's little difference
> between a single commit and 2-3 commits as a group.  Yes, there's a bit
> more difference when you're cherry-picking them to other branches, and
> maybe an infrastructure/procedure change could help with that; but
> once they're there in history, it doesn't hurt to have three separate
> commits doing related work, keeping the distinct parts distinct.

Every commit to a 3.x maintenance branch (now 3.4) must be forward 
merged into the 3.(x+1) default (now the future 3.5), even if it is just 
a null merge. The point of this policy is to keep the repository in a 
coherent state. If a bug were fixed in maintenance but not default, it 
would create a regression situation, the same as if it were fixed in 
default and then broken again by a separate patch.

Part of the planned (hoped-for) change (using a system that is already 
working for another project with even more code and committers) is to 
automatically test patches on the buildbots before they are committed to 
the central repository, rather than after. Each would be tested and 
accepted or rejected separately. So each commit would have to stand on 
its own even more than now.

-- 
Terry Jan Reedy