Eric Sandeen wrote:
> "D. Stimits" wrote:
> > Are tags issued as standard practice at each sync? E.G., is there any
> > problem with naming a tag to get the 2.4.6-pre3-xfs or 2.4.6-xfs at any
> > time, despite the fast changes? (what tag name scheme is used?)
> I'll have to look into this, CVS is pushed out automatically from our
> own internal source code management tools, and I'm not sure if the
> concept of a CVS tag can make it from one to the other - it may take
> some manual manipulation of the CVS tree. A few people have asked for
> this, if there's a good way to do it, maybe we can get more diligent
> about it.
> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
> sandeen@xxxxxxx SGI, Inc.
A temporary workaround (which could actually work for quite a while)
would be if a web page gave the time/date to use for date-based
checkout. Even without explicit tags at each stage, if you know the
date/time, you can check out "the most current as of date/time being
xxx". What I'm not too certain of is whether there is any problem with
dates and times being set differently on different machines. In the
latter case, there'd have to be some sort of conversion by each person;
if a single README.SGI.cvsversion file was created, and the person
checking in the final cvs change that officially syncs with a known
kernel release version has that information placed in the README as the
final checkin act, then it would be someone easy to know if things had
been retrieved correctly. The README could contain something as simple
"This is the final checking for 2.4.7 pre1 before beginning 2.4.7 pre2."
(and the time/date might be interesting)
Then one could check out based on that time/date, and verify any
timezone differences this way. Once the README is set, the first checkin
after that should probably alter the README to something like this:
"This is an intermediate revision building towards 2.4.7 pre2."
D. Stimits, stimits@xxxxxxxxxx