From owner-freebsd-stable  Wed Oct  8 12:53:29 1997
Return-Path: <owner-freebsd-stable>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA10634
          for stable-outgoing; Wed, 8 Oct 1997 12:53:29 -0700 (PDT)
          (envelope-from owner-freebsd-stable)
Received: from emout15.mail.aol.com (emout15.mx.aol.com [198.81.11.41])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA10627
          for <stable@freebsd.org>; Wed, 8 Oct 1997 12:53:26 -0700 (PDT)
          (envelope-from Hetzels@aol.com)
From: Hetzels@aol.com
Received: (from root@localhost)
	  by emout15.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0)
	  id PAA07459;
	  Wed, 8 Oct 1997 15:52:54 -0400 (EDT)
Date: Wed, 8 Oct 1997 15:52:54 -0400 (EDT)
Message-ID: <971008155108_-1194179101@emout15.mail.aol.com>
To: nate@mt.sri.com
cc: 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-08 15:03:48 EDT, nate@mt.sri.com writes:

> > >  I suggest spending less time arguing, and more time coming up with a
>  > >  *solution*, and not a proposed solution.  Changes to the tree,
>  > >  newvers.sh, etc....
>  > >  
>  > We're trying to come up with the solution but it basically, involves
three
>  > areas.
>  > 1. Creation of a .timestamp file added to the source tree.
>  
>  Sure, the only thing that's disagreed upon is the format of the
>  timestamp, and how often it's built.  *THIS* is the crux of the matter,
>  and if you can come up with *something*, then the rest is politics.

This file is re-created at the Master Source Repository, every time someone
updates the source tree.

NOTE: There would be a different timestamp file in each Branch (3.0, 2.2,
2.1) that needs to be tracked.

>  
>  > 2. Create a new newvers.sh that sets the timestamp.
>  
>  No, you want newvers.sh to *use* the timestamp.  newvers.sh is used
>  everytime you build a kernel, so you want to use the information from
>  it.

What I meant to say is that newvers.sh uses the .timestamp file to set it in
the kernel.

>  
>  >   a. "uname -r" should output the release level. And I believe that 
> everyone
>  > is in agreement that it should use a timestamp instead of some counter.
>  
>  That's a political issue.
>  
>  >   b.  "uname -v" output. Currently, we're tring to decide if the
CURRENT,
>  > RELEASE, STABLE tags should go or stay.
>  > 
>  > I'm for keeping them as it makes it clear as to what the user is
running.
>  > 
>  > RKW, is for removing them.
>  
>  Once the solution is in the tree, we can argue about what it says. :)
>  
>  > I currently have a patch to newvers.sh that uses a .timestamp file.
 This
>  > will cause uname -r to show the release level + time stamp.
>  > 
>  > 2. Master Source Repository
>  > 
>  >   The .timestamp file has to be created after each update to the source
>  > trees.
>  
>  OR at some regular interval.  This time-stamp has to be part of the CVS
>  tree *and* available to *all* kernel users.  How do you do that?
>  
>  >  How do we implement timestamp so that it updates the .timestamp file at

> the
>  > Master Source Repository?
>  > 
>  > This is the only real question left.
>  
>  That's the only real issue IMHO.  The rest is politics, and can be
>  argued about with no agreement until hell freezes over with no
>  resolution.  Give me *A* working solution, and then whoever can argue
>  about making it a better solution.  Something is almost always better
>  than nothing, especially in this case.  If you can come up with *a* good
>  solution, and no-one can come up with an agreement on a 'better'
>  solution, the good one will be 'good enough'.
>  
>  Talk is cheap, especially since people like me can get involved. :) :)
>  
This is the one solution I don't know how to solve, the rest was easy.

1. What is the Master Source Repository using to track the source code?
(RCS?)

2. How do you go about implementing a hook in to the source tracking code so
that it will automatically update the ".timestamp" file after each update to
the source tree.

pseudo code:

     Check out ".timestamp"

     date "+%C%m%d%H%M" > ".timestamp"

     Check in ".timestamp"

3. Would it update the timestamp file after each file is checked in or after
the person updating the source tree has finished?

Scot