QA-oriented features for a version control system

Michael Elizabeth Chastain mec.gnu@mindspring.com
Sat Jun 5 04:12:00 GMT 2004


Here are three QA-oriented features that I would like to have
in a version control system.

(1) Better support for regression searching.

    With CVS, first I find a date where the software worked, then I find
    a date where the software is broken.  Then I do a binary search on
    the dates in between to find the particular changeset that causes
    the bug.

    First of course I want the changesets to be atomic, but that's already
    a requirement and it seems that every post-CVS version control
    system supports this.

    But what I really want is to search the line-of-development using
    some kind of "changeset index" rather than a date.  I.e, if there have
    been 220 checkins between 2004-05-01 and 2004-05-15, the
    "changeset index" should increase by 220.  Then I want to do checkouts
    by line-of-development + changeset-index, rather than line-of-development
    + date.  That way, it is much easier to find the particular changeset
    that introduced a particular bug.

    The way we use CVS, the revision number of "ChangeLog" is similar
    to the "changeset index" that I want to have.

    It would be really kick-ass if I could say: "give me all the changesets
    between point LOD.X and LOD.Y", in some kind of delimited way,
    so that I can read each changeset.

    Anways, I'm wandering over the line into design.  My requirement is:
    I want it to be simple to do ordered searches in the past.

(2) Explicit reproducible checkouts

    Right now, if I do "cvs checkout", I get something that is not
    guaranteed to be reproducible by other people.  I work around this
    by doing "cvs checkout -D $DATE", where $DATE is the current date
    minus three minutes.  This works as long as the clock on my client
    machine is sync'ed to an ntp source and the clock on the cvs server
    is also sync'ed to an ntp source (which I assume it is).

    One drawback is that after "cvs checkout -D $DATE", all the files
    have sticky tags.

    I want this to be simpler.  When I do "cvs checkout", I want to
    get some info which I can put in a PR so that anyone else can
    reproduce the exact same checkout that I got.  If the version
    control system has a notion of "changeset index", then
    "line-of-development + changeset index" would be such a key.

(3) Get Server Date

    If the version control system uses dates as control parameters,
    like CVS does, then add something to the client-server protocol
    so that the client can query the server for the current date!

    It's a wart in my scripts that I have to use dates in cvs,
    but I don't know really what time it is on the cvs server.

Michael C



More information about the Gcc mailing list