From owner-freebsd-stable  Sun Oct  5 05:30:42 1997
Return-Path: <owner-freebsd-stable>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA16185
          for stable-outgoing; Sun, 5 Oct 1997 05:30:42 -0700 (PDT)
Received: from emout05.mail.aol.com (emout05.mx.aol.com [198.81.11.96])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA16178
          for <freebsd-stable@freebsd.org>; Sun, 5 Oct 1997 05:30:40 -0700 (PDT)
From: Hetzels@aol.com
Received: (from root@localhost)
	  by emout05.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0)
	  id IAA26488;
	  Sun, 5 Oct 1997 08:30:01 -0400 (EDT)
Date: Sun, 5 Oct 1997 08:30:01 -0400 (EDT)
Message-ID: <971005083000_1543650796@emout05.mail.aol.com>
To: chad@dcfinc.com
cc: freebsd-stable@freebsd.org
Subject: Re: CVSup release identity
Sender: owner-freebsd-stable@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In a message dated 97-10-04 18:27:20 EDT, chad@freebie.dcfinc.com writes:

> > I agree that it needs a little work in order to support cvs & ctm.
>  > One thought is to make .ctm_status a permant part of the source tree
>  > and to have an additional file .cvs_status that would be used to track
>  > version #'s of source files that have changed between each CTM delta.
>  > That way a CVS user could pull down modified source files and know how
>  > far off from the CTM delta they are.
>  
>  Reverse the thinking.  Make .cvs_status a permanent part of the tree,
>  and increment it each and every time a change is comitted.  Then there
>  is a known place to get a marker of where along the line of updates a
>  particular system resides.
>  
I see one problem with a permanant .cvs_status file.  If commiter A changes
files X,Y, & Z, does he increment .cvs_status for each file or per change.
 Then if 2 commiters A (X, Y, Z) & B (D, E) change files which one changes
the .cvs_status file.  What prevents them from submitting the same change to
the file?

A tool that would automaticly update the .cvs_status file would then be
needed.  I suggested the .ctm_status file because there is already such a
tool to create this file.  Besides how fine a grain do you need?, An Exact
version identity, or at least knowing that your between point A & B.  Thus,
if someone reports a bug at point A, and it is fixed at point B, all anyone
has to say is update your system to at least point B and your problem is
solved.  Since CTM deltas are created every so often during the day, it makes
the perfect choice to track where the source tree is at during any given time
period.

Scot