[Top][All Lists]

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

Re: history of the tags (was: hitory of the tags)

From: Mike Sutton
Subject: Re: history of the tags (was: hitory of the tags)
Date: Wed, 29 Nov 2000 08:10:32 -0500
User-agent: Mutt/1.2.5i

Why not use a taginfo trigger to capture tag data.   Below is a sample
output of the perl script I use.

Repository:   /cvs_repositories/m2k_cvsroot/m2k/PCP_DEV/Players/AirCAT/src
Tag:          RadCAT_Version_0_2
Operation:    add
Date:         Fri Nov  5 15:55:01 1999
Tagged-By:    larkinbr

    File: AirCAT.cdf                                          Revision:
    File: AirCAT.h                                            Revision:
    File: AirCAT_Platform.cdf                                 Revision:
    File: AirCAT_Platform.h                                   Revision:
    File: AirCAT_Platform_func.cpp                            Revision:
    File: AirCAT_func.cpp                                     Revision:
    File: files.make                                          Revision:
    File: makefile                                            Revision:

Mike Sutton                      | public class
SAIC                             | software_failure : management_failure
Beavercreek, OH                  | 
address@hidden                 | These are MY opinions, not SAIC's

On 11/28/00 17:24:57, Derek R. Price wrote:
> Donald Sharp wrote:
> > Here's a first crack at it.  Probably still needs some work, but wanted
> > to get some feedback ;)  It's attached to the end of this email...
> That's not a complete fix.  Here's what I noticed:
> 1)  There's no filename or directory saved to the history log, leaving the
> user with no idea which files were tagged.  You need to list both filename
> and directory since, unlike rtag, tag can specify individual files, each
> tagged file must be listed in the history separately, like a commit history
> entry.  Note that this will require a new record type.
> 2)  'A' is not really appropriate in lieu of a revision number or symbolic
> "base" tag.  A user would have to run a second command to find which revision
> number the tag was attached to.  This information should be added for the tag
> delete log too since the user would not have to trace back through the log to
> find what the last tag op to that file was to know where the delete happened
> - information which might not be available if the history log was ever reset
> and which would be hard to calculate based on the current rtag logs.  I would
> advocate that the symtag should be listed if in the original tag command, but
> whatever the final affected numerical tag is should be listed too.  If the
> tag was a move that should probably be listed too, perhaps as a "delete" then
> a "tag", but a single entry might be more succinct and there should still be
> plenty of namespace, especially if you make "delete", "add", and "move" sub
> record types of "tag".  I'm thinking it might be appropriate to alter rtag to
> use the new log format as well.
> 3)  Don't forget that a final patch submission should contain a ChangeLog
> entry and any necessary doc changes, but I'm sure I didn't need to remind you
> about that.  :)
> Derek

reply via email to

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