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

[Thornley, David]

> -----Original Message-----
> From: Derek R. Price [mailto:address@hidden
> Sent: Friday, August 10, 2001 10:07 AM
> To: James Youngman
> Cc: address@hidden; address@hidden
> Subject: Re: What's remembered? "S" flag suggestion
> 
> 
> Don't ask me!  The point of this was that I don't really have any
> particularly strong opinions on this issue yet.  Convince 
> some of the other
> people out there and maybe I'll venture an opinion.  It's 
> probably worth
> noting that `cvs -qn up' seems to accomplish much the same 
> thing as your
> script (aside from the file counts), though I haven't 
> actually tested the
> script and my awk is a bit rusty.
> 
Here's the warnings I'd like to see on update.

1.  File has sticky non-branch tag or date or rev

2.  Files in one directory, or one update, have different
    branch tags (or lack of same).

I've had problems with both of these from time to time.  Both are,
in my practice, exceptional situations.  I wouldn't want to forbid
operations in these circumstances, but they exist sufficiently
rarely that I'd like to be reminded when they're there.

> I think I have been persuaded by the original argument in 
> this thread that
> "S" (or "T", but I'm not sure I like the overloading since 
> for tag & rtag,
> "T" can mean a branch or a static tag) is a useful status 
> message from `cvs
> update' when the user tries to update a file with a static 
> tag.  Or perhaps
> "S" for static tag and "s" for static tag but modified file 
> or something,
> but that has the potential of breaking scripts which were 
> dependent on the
> 'M'.
> 
You can't rely on the 'M' anyway to denote modifications, since a
modified file might be listed as 'C'.  Adding another letter to
look for isn't as much of a pain when there's already two.

> Well, okay, I guess this deserves more discussion then.  
> Anyway, how about a
> single warning for all files when the sticky static tag is 
> discovered.  On
> stderr probably.  It seems to me that this would provide the requested
> functionality as well as preserving the old API, for the 
> majority of cases
> (bulk/recursive operations).  In the rare exceptions, the 
> user could resort
> to `cvs status' to trace the source of the problem if they wished...
> 
I could go with a simple stderr warning.  It would be better than
what we've got now.  Basically, these are exceptional situations where
I'd like to be alerted.  More information might be useful (a "cvs status"
listing is rather long for a large directory, and there's nothing to grep
out that lists both the file name and the sticky tag/date), but I can
always write something in Perl to grab the information.