[Zope3-dev] Re: [Zope-Coders] Re: [Zope-Checkins] CVS: Zope3/src/ZConfig/tests - test_schema.py:1.10.2.1

[Chris McDonough]

One other strategy that I learned the hard way with the
chrism-install-branch is that you almost never want to tag *all of Zope*
at the root with a branch tag.

Instead, if you're not making sweeping changes, tag only the packages
that you know you're going to change.  Merging the smaller packages is
much less painful and generates fewer checkin messages; the rest of Zope
can be on the trunk and you needn't do anything.

If you're not sure what packages you'll be changing, do a bit of work
without checking in for a while until you get a good sense of where
you're going to be making most of the changes.

My $.02,

- C


On Tue, 2003-02-11 at 20:36, Tres Seaver wrote:
> On Tue, 2003-02-11 at 09:41, Sidnei da Silva wrote:
> > Update of /cvs-repository/Zope3/src/ZConfig/tests
> > In directory cvs.zope.org:/tmp/cvs-serv18615/src/ZConfig/tests
> > 
> > Modified Files:
> >       Tag: paris-copypasterename-branch
> > 	test_schema.py 
> > Log Message:
> > Updating from HEAD to make sure everything still works before merging
> 
> I would like to lobby the zope-coders community for an explicit ban on
> this practice, with the ban to be waived only in very exceptional cases.
> "Back-merging" from the HEAD to your branch is a dubious practice at
> best, even for branches which expect to outlive the merge by a
> significant period of time:
> 
>   - The "backmerge" checkins create noise for those who review the
>     checkins;  your backmerge created some 60+ totally spurious
>     messages, followed by another 60+ two hours later as you merged
>     them in together with the "real" changes.  I try hard to read
>     the checkins for both the Zope and the Zope3 repositories, which
>     I consider to be a significant contribution to the code quality
>     under the rubric, "Given enough eyes, all bugs are shallow."  Huge
>     checkins like these defeat that practice, as I can't find the
>     "substantial".changes amid the noise.
> 
>   - The "backmerged" changes obscure the intent of the branch:  it is
>     now impossible to use the CVS machinery to tell just what changed
>     on the branch.
> 
>   - What you really wanted to do today was to get your sandbox
>     to the HEAD, then merge your branch to it, taking only the
>     "minimal" diffs on the branch.  You could've then tested and
>     checked in on the head, and marked the branch as "retired".
> 
>   - Release branches, which do need to merge backported fixes, are
>     a slight exception:  slight because the stability mandated by a
>     release branch explicitly outlaws merging anything other than the
>     smallest possible changes required to support the backport, and
>     therefore won't lead to the problems.
> 
> This isn't intended as criticism of Sidnei's work, but a plea to change
> our *consensus fidelium* away from the practice.
> 
> 
> Tres.
> -- 
> ===============================================================
> Tres Seaver                                tseaver@zope.com
> Zope Corporation      "Zope Dealers"       http://www.zope.com
> 
> 
> _______________________________________________
> Zope-Coders mailing list
> Zope-Coders@zope.org
> http://mail.zope.org/mailman/listinfo/zope-coders