[freeciv-ai] Re: uploaded new versions of teams and massive AI patches

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 10:15 AM 02/10/21 +0000, Per I. Mathisen wrote:
>On Sun, 20 Oct 2002, Ross W. Wetmore wrote:
>> Committing a massive patch should not be a problem. But before doing this
>> it should go through parallel scrutiny or exercising by several people.
>> Just run it for a week or two as the dev-branch of choice for several
>> developers.
>
>For the current massive AI patch, I don't see why testing it out as a huge
>diff is more difficult than testing it out as a branch.

You aren't thinking this through ... by branch one just means a working 
environment for a group of people actively hacking in that area. By 
"using" the massive patch rather than just "testing" it for a couple 
minutes, it will get far more workout. 

>> This is why having several people maintain a dev-branch and
>> do most of their work on it with periodic resyncs from headrev and a final
>> back checkin is a good way to handle area specific projects.
>
>It gets less transparent this way. It gets *much* harder for people to see
>which changes do what and are connected to which change when it is part of
>a huge final diff between trees.

Again, you aren't following the thoughtline. The many small diffs are
all captured in the individual checkins on the branch. The big diff 
only occurs for the final mainline sync where it is more important that 
a single consistent checkin of the entire effort be done.

And by excluding any small diffs from "unrelated" areas of work, the 
history of the large patch component is much easier to follow. Mixing
everyone's small hacks in a big melting pot makes it almost impossible
to track or understand larger project activities as unit wholes.

[...]
>> <GB>
>> In the future we should avoid doing this.In particular, we can commit
>> small changes faster, to avoid patch entanglement.
>> </GB>
>
>I agree completely with GB on this. My massive AI patch is an unfortunate
>abberation.
>
>  - Per

You are both confusing the desirability of lots of little checkins with
the process of maintaining consistency in a larger whole. The thing you 
are not taking into account is that you can do the small checkins in lots
of parallel threads with only periodic big merges between the threads.

In addition to a stable development environment on any thread since you
control when you want to import mainline updates, you get much more 
stability on the mainline if the dev-branch project is completed, sync'd 
with the mainline, tested and then merged back into the mainline as a 
single update. The merge back is a simple copy/replacement if no other 
mainline activity has occurred since the last dev-branch sync.

In effect this is what you do when you resync to CVS, add a patch, test
it out and merge it back into CVS. The dev-branch just allows you to 
keep track of more than one patch step, or updates from the active group
of developers working on a larger feature, between CVS checkins. Thus
you can deal with larger features than trivial bugfixing updates.

This is a far superior way to handle things. Read up on some of the ways
of doing development at (http://www.berczuk.com/scm-patterns-book/). The
Brad Appleton site is another useful one that describes a number of
varied development patterns.

Lots of little untested or poorly tested patches flooding into CVS from
unrelated development efforts will only confuse things more.

Cheers,
RossW
=====