From owner-freebsd-current  Fri Jun  7 16:07:14 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA02203
          for current-outgoing; Fri, 7 Jun 1996 16:07:14 -0700 (PDT)
Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA02154;
          Fri, 7 Jun 1996 16:07:02 -0700 (PDT)
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA01251; Fri, 7 Jun 1996 17:06:47 -0600
Date: Fri, 7 Jun 1996 17:06:47 -0600
From: Nate Williams <nate@sri.MT.net>
Message-Id: <199606072306.RAA01251@rocky.sri.MT.net>
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: Nate Williams <nate@sri.MT.net>, hackers@freebsd.org (FreeBSD Hackers),
        freebsd-stable@freebsd.org (FreeBSD Stable Users),
        FreeBSD-current@freebsd.org (FreeBSD current users)
Subject: Re: The -stable problem: my view 
In-Reply-To: <16852.834188423@time.cdrom.com>
References: <199606071529.JAA29241@rocky.sri.MT.net>
	<16852.834188423@time.cdrom.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > doing a *ton* of work in both -stable and -current.  However, it's a
> > *LOT* of work.  However, I don't think this has anything to do with CVS,
> > but has to do with the diverging of the trees.  P3 may make it easier to
> > do as far as resources, but the actual work of 'merging' in changes to
> > both won't be any easier.  Building the patches is the hard work IMHO,
> 
> I think you're forgetting the problem with cvs where:
> 
> 1. You make a change in -release.
> 2. You merge it into -stable.
> 3. You make another change in -release.
> 4. You go to do another merge into -stable and wind up with a whole *mess*
>    of conflicts.  `cvs update -j' is NOT a decent merge tool!

I don't use 'cvs update -j' to merge it into -stable.  'merge' doesn't
work when you've already merged.  What *I* do is this, which is a bit
more work but does do the job 95% of the time.

% cvs log file-to-merge.
(Figure out which revision(s) needs to go into the branch).
% cvs diff -c -r1.A -r1.B file-to-merge > cdif
% cvs update -r BRANCH_TAG 
% patch file-to-merge < cdif
....
% emacs -nw file-to-merge file-to-merge.rej
....
% cvs diff -bu file-to-merge
[ Review the merged patch, make sure it's ok, build/test/etc. on my box ]
% cvs commit file-to-merge

This is alot of work, but it *does* the job.  Whole-scale merging of
trees and directories doesn't work when the trees have already been
merged.  CVS doesn't operate on the principal of 'everlasting' branches
that keep getting 'merges' happen to them.  As I understand the CVS
model, if we merged everything into -stable, then we should build a new
branch at that point in -current since the files are merged.

Merges are 'merges', not 'sort of merges'.


Nate