Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Oct 1997 15:52:54 -0400 (EDT)
From:      Hetzels@aol.com
To:        nate@mt.sri.com
Cc:        stable@freebsd.org
Subject:   Re: CVSup release identity
Message-ID:  <971008155108_-1194179101@emout15.mail.aol.com>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?971008155108_-1194179101>