Complete.Org: Mailing Lists: Archives: freeciv-ai: October 2002:
[freeciv-ai] Re: uploaded new versions of teams and massive AI patches

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <per@xxxxxxxxxxx>
Cc: Freeciv AI development <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: uploaded new versions of teams and massive AI patches
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Sun, 20 Oct 2002 19:53:15 -0400

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. 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.

If the massive dev-branch is as stable as the CVS headrev-branch (or as
unstable), it really doesn't matter which one becomes the new headrev.
And if headrev is not troubled by lots of little changes, other area
specific projects need only do periodic resyncs rather than living in
an ongoing free-fire zone.

Lot of little unchecked patches with interactions are no better than a 
single unchecked big one. The former although unusal practice is no safer
and if not exercised nearly as much before checkin may be buggier.

In the future we should avoid doing this.  In particular, we can commit 
small changes faster, to avoid patch entanglement.

This is what you get on the dev-branch where people are much freer with
checkins than with the resistance-mode of the CVS mainline. You can always
go back to the dev-branch to pull out smaller pieces of a massive patch
if you really need to see the isolated subset. And since they all hit the
mainline at the massive patch checkin, there is less muddling of them with
lots of other little patches from unrelated project work.

Lots of little mainline patches, conversely, is a much poorer way to proceed
as everything gets scrambled and you lose the larger coherence as well as
tending to waste more time on frivolous maintenance aspects and throw away
code to do things piecemeal.


At 06:52 PM 02/10/16 +0000, Per I. Mathisen wrote:
>On Wed, 16 Oct 2002, Gregory Berkolaiko wrote:
>> Oh...I am not sure I can do it easily.  I'll try to find the change I
>> made though, it might be easier...
>Please do.
>> Is it a problem to commit massive as a series of patches?
>I am afraid so. It is near impossible now to split it up back into its
>constituent patches. I've made so many interconnected changes.
>  - Per

[Prev in Thread] Current Thread [Next in Thread]