This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: QA-oriented features for a version control system
Michael Elizabeth Chastain wrote:
> Here are three QA-oriented features that I would like to have
> in a version control system.
Hmm, I'm going to sound like a bit of an SVN fanboy. Oh well. It covers what
you want to do very well :-). I try not to be a fanboy to anything, but I
do think that in general SVN has done a pretty good job of accomplishing
it's goal of "a better CVS"; new features without earthshaking changes in
philosophy :-)
> (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.
Yeah, I haven't seen anything new in a long time that doesn't at least get
this right.
> 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.
This is, in fact, how subversion works. Rather than CVS's per-file version
numbers, it keeps a global revision number for the repository, incremented
for every change that is committed (a change can, of course, consist of
multiple file updates, additions/removals/renames/etc - whatever was
committed in one atomic changeset). Now, one consequence of this is that in
any given file/folder the set of changes between n and n+1 can be empty
(since the changes might not have touched that part of the tree), but
ignoring "no changes" is quite easy. And it makes the job of searching the
changes like you wanted very simple:
svn diff /branches/NAME/src/tree -r 500 -r 510
or, if you like, you can also specify revisions by date, in which case it
will find the revision which was effective on that date (the last one
committed before it). It also has a few special names, like PREV, which are
helpful in finding the last change before the current state (since, as I
said above, n-1 may be identical if the changes were elsewhere)
> (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.
Subversion does tagging and branching in the filesystem namespace (as a
versioned copy that knows what point it branched at), so line of
development is just repository pathname. And, since it has a global
revision index, and atomic changesets, pathname+revision is your desired
unique identifier for the tree that your checkout resulted in.
> (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!
Of course, any attempt to do this is somewhat racy; but you knew that. It's
a CVS wart that you need to care anyway.
I don't know of any specific support for this in any current version control
system, but if the server is running time service (typically via the
builtin in inetd) you can ask it via rdate... so there's probably no point
to build it into the revision control.
> 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