[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: querying non-rtags?
Re: querying non-rtags?
Mon, 05 Mar 2001 16:07:06 -0600
I noticed that the technical part of my question was answered by Larry
Jones answering another question earlier on Sunday.
So thanks, indirectly, for that. However, the "process advice" part of
my question still stands. If any of you have the time, I'd definitely
appreciate advice on that.
Alexander Kamilewicz wrote:
> Hi all,
> I feel bad that since my original question a few months ago I haven't
> tried to answer anyone else's questions. I hope that eventually I'll
> feel comfortable enough with CVS to really help out people.
> That said, I need help. I know that:
> $cvs history -T -a | grep modulename
> will get me a listing of all rtags attached to modulename. Which is
> good. However, I've recently developed a need to know what regular tags
> (i.e. the result of cvs tag) have been applied to a certain module,
> especially in the period since my last build (a build being when I apply
> a rtag to the whole module's HEAD).
> Aside from going through every file via:
> $cvs log filename
> there doesn't seem like a way to do this.
> Why do you want to do this?, you might be asking. I don't blame you.
> Here's the scoop. The Powers That Be (TM) have decided that we want to
> employ a "gatekeeper" structure for development & builds. The way this
> works is as follows:
> 1. Developers do stuff and when they've finished a "feature" or,
> perhaps "fix", they use $cvs tag tagname filenames to "tag" their work.
> 2. After the code freeze and before the build (which is me doing cvs
> rtag and then updating our test box with said tag), the "gatekeeper"
> will look at all "tags" and decide what "features" and/or "fixes" will
> go into the build.
> 3. I'll do the build via a function of re-tagging the "features" or
> "fixes" as that build version:
> $cvs rtag -r patchtag buildtag (this is both simpler than rtagging
> every file that we want in the build, but also has the benefit of
> excluding files that have been changed in the module but that we don't
> want in the build)
> 4. If the build has problems, I can revert the changes by deleting the
> rtag from the files in question ($cvs rtag -d buildtag filename), which
> actually leads to a tangential question:
> -is it possible to do this using patchtagname instead of filename?
> -$cvs rtag -d buildtag patchtag, for instance, which didn't work for
> If you've managed to fight off boredom and follow the above steps,
> you'll see why it would be helpful for me to find a easy, quick &
> painless way to find the developers' "tags" for their fixes and
> Now, I _have_ figured out a way to do this, but it's cumbersome. Here
> it is:
> 1. $cvs -q rdiff -s -r buildtag -r HEAD foomodule > diff
> This builds a file that lists all the files that changed with each line
> looking something like: File foomodule/bar/zap.htm changed from 1.1 to
> 2. use "cut" to get rid of the stuff before and after the filenames
> 3. use a script with the following bit to put "cvs log" in front of
> each filename:
> for i in 'cat diff'
> echo cvs log $i
> 4. run script
> OK, so that's it! Thus, I've got 2 questions:
> 1. Is there any easier way to accomplish that which I've laid out
> 2. Does anyone have similar experience to this kind of development
> "environment" with these needs and how did you fulfill them?
> Thanks a ton in advance!!!!!