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>
index | next in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?971008155108_-1194179101>