info-cvs
[Top][All Lists]
Advanced

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

Re: How to baseline project for subsequent releases


From: Maxim Senin
Subject: Re: How to baseline project for subsequent releases
Date: Mon, 1 Apr 2002 21:08:21 -0800

Thank you.

----- Original Message -----
From: "Greg A. Woods" <address@hidden>
Newsgroups: comp.software.config-mgmt,fa.info-cvs,gnu.cvs.help
To: "msenin" <address@hidden>
Cc: "CVS-II Discussion Mailing List" <address@hidden>
Sent: Monday, April 01, 2002 6:17 PM
Subject: Re: How to baseline project for subsequent releases


> [ On , April 1, 2002 at 16:16:21 (-0800), msenin wrote: ]
> > Subject: How to baseline project for subsequent releases
> >
> > Please help me, CVS beginner, on this:
> > For every release we build, we need to know which version of which
> > file went into release.
> >
> > How do we do that with CVS?
>
> Assuming you've tagged your release (a sadly mistaken assumption it
> seems) it's a trivial task to take the output of a command such as the
> following to generate your list:
>
> cvs -q rdiff -s -r 1.1 -r RELEASE-TAG-NAME MODULE-NAME
>
> You could also write a relatively simple 'sed' (or awk or perl or
> python or ruby or tcl or ici or icon or basic or rexx or scheme or
> elisp, or you get the idea....) program filter the output of:
>
> cvs -q rlog -h -r RELEASE-TAG-NAME MODULE-NAME
>
> and thus generate the list....
>
> You could of course also check out the release by tag and then use
> either "cvs log" or "cvs status" to create the list from within the
> resulting working directory.
>
> > I believe task can be simplified if we tagged all files with same
> > version name for every release, but we'd preffer not to change
> > versions of files that haven't been modified.
>
> Huh?  You can have multiple tags on any given revision.  Hundreds.
> Thousands even.  Tags don't "change" anything -- they're effectively
> just pointers, and they map a symbolic name to an internal revision
> number.
>
> You really Really REALLY should tag releases -- that's how you identify
> them after the fact with CVS!
>
> The whole point to using tags to mark releases is to apply the same
> symbolic (tag) name to every related revision in a given module!
>
> If you use tags to mark your releases there's really not much point to
> getting a list of the internal revision numbers a given tag points to.
> Those revision numbers are really only internal sequence numbers for the
> deltas recorded in the RCS repository managed by CVS.  The only reason
> you might want to record this internal information is as an audit trail
> to make sure nobody moves or removes a release tag in the future (in
> which case you need to store it in a separtely secured place, of course).
>
> --
> Greg A. Woods
>
> +1 416 218-0098;  <address@hidden>;  <address@hidden>;
<address@hidden>
> Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird
<address@hidden>
>




reply via email to

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