From owner-cvs-user  Sat Sep 16 12:57:01 1995
Return-Path: owner-cvs-user
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id MAA06064
          for cvs-user-outgoing; Sat, 16 Sep 1995 12:57:01 -0700
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA06026
          ; Sat, 16 Sep 1995 12:56:52 -0700
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id MAA01779; Sat, 16 Sep 1995 12:56:33 -0700
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199509161956.MAA01779@GndRsh.aac.dev.com>
Subject: Re: heads-up, eBones repository operation about to happen..
To: gibbs@freefall.FreeBSD.org (Justin T. Gibbs)
Date: Sat, 16 Sep 1995 12:56:32 -0700 (PDT)
Cc: peter@jhome.dialix.com, cvs-committers@freebsd.org, cvs-user@freebsd.org
In-Reply-To: <199509161723.KAA05838@aslan.cdrom.com> from "Justin T. Gibbs" at Sep 16, 95 10:23:59 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1828      
Sender: owner-cvs-user@freebsd.org
Precedence: bulk

> 
> >On Sat, 16 Sep 1995, Peter Wemm wrote:
> >And, I've now restored ~ncvs/src/eBones from that backup and done:
> >
> >peter@freefall> cvs -q rtag -d RELENG_2_1_0 eBones
> >peter@freefall> cvs -q rtag RELENG_2_1_0_NEW_BP eBones
> >peter@freefall> cvs -q rtag -b -r RELENG_2_1_0_NEW_BP RELENG_2_1_0 eBones
> >
> >We still have that backup, so if anybody wants any modifications to this, 
> >yell..
> >
> >-Peter
> 
> I don't understand what the RELENG_2_1_0_NEW_BP gets us.

Neither do I really, except the ability to get a diff for the eBones area
from the point just _before_ the massive reorg, which might come in handy.

But the important thing is that it is now possible to get back to the
original 2_1_0_BP which was destroyed very soon after this whole thing
was started.

So others know (I have been emailing back and forth with Peter privately)
once a _BP tag is layed down that ``state'' should for ever remain exactly
as it was.  This means you do not every apply that tag to additional files
and you must delete that flag from any file you copy in the repository.

For one of the reasons (there are many more) that this _BP tag exists see
the ``complicated'' version of major branching and merging in the CVS
FAQ.
Basically it is used to manually do sanity checks on the 3 way merge
that would happen if you did this:

cvs co src
cd src
cvs update -jRELENG_2_1_0_BP -jRELENG_2_1_0

But it is also very usefull for doing things like:
cvs rdiff -u -rRELENG_2_1_0_BP -rRELENG_2_1_0 module

to see what changes have been made on the branch to a specific model,
adding and removing files _should_ show up as deltas, if you move the
_BP tags around they don't :-(.

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD