[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's remembered? "S" flag suggestion

From: Eric Siegerman
Subject: Re: What's remembered? "S" flag suggestion
Date: Tue, 7 Aug 2001 12:25:56 -0400
User-agent: Mutt/1.2.5i

On Mon, Aug 06, 2001 at 12:00:58PM -0400, Derek R. Price wrote:
> "David A. Cobb" wrote:
> > On one project I checked out a specific tag (xemacs: CVS co -r
> > r21-5-latest-beta...).
> >
> > Since then, I have been surprised to find that PCL CVS-Update finds
> > everything up-to-date dispite being on the edge of the development line.
> Yeah, CVS does remember.  You probably want 'cvs up -A'

And that it remembers is a Good Thing.

At the same time, though, it's a bit annoying that a "cvs update"
doesn't inform/remind one about sticky release tags.  I've been
fooled by this:  Do an update, check over the output.  It didn't
complain about anything (besides the usual collection of "?"
cruft -- my sandboxes tend to get pretty messy, like my desk
:-/).  "Oh good, I'm up to date", I think.  WRONG!  Because
there's that one file I did a "cvs update -r1.5" on three days
ago due to 1.6 being buggy.  (Once the fix gets checked in, of
course, I intend to do a -A on the file.)

If there's a sticky release tag on a file, cvs should tell me.
How about a new status code from "update":
        S foo.c
(or "T" -- maybe it's ok, or even preferable, to overload the
latter since currently only "tag" and "rtag" use it).

ISSUE: Should it print this for *every* sticky-release-tagged
file, or only those where the tag is preventing an update to the
latest revision?  I.e., if I do "cvs update -r1.5 foo.c" when 1.5
is HEAD, should it flag the file with "S" or be silent about it?

For the use case above -- avoiding the HEAD revision because of a
bug -- the ideal would be to stay silent, whether or not the
sticky-tagged revision is the latest, until someone checks in a
new revision (subsequent to the command that set the sticky tag
in the first place):
        - Someone checks in 1.6.
        - I find a showstopper bug.  I ask them to fix it; to
          continue working in the meantime, I do:
                cvs update -r1.5 foo.c
        - "cvs update" in my sandbox is silent about foo.c, even
          though I'm not getting the latest rev.
        - Someone checks in 1.7
        - "cvs update" in my sandbox starts saying
                S foo.c
          thus reminding me to check whether it's time to remove
          my sticky tag.  If it isn't (the bug's still not
          fixed), I can silence CVS by repeating:
                cvs update -r1.5 foo.c
        - "cvs update" will resume printing "S" messages for
          foo.c once rev. 1.8 has been committed.

That'd be nice, but it's probably infeasible -- I don't think the
current data structures have anyplace to store the extra
rev-number / tag-name ("1.6" in my example).  For that reason, I
mention this theoretical ideal not as a serious suggestion, but
only as a point of departure for choosing among the feasible


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]