autoconf
[Top][All Lists]
Advanced

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

Re: Autoconf 2.49e


From: Eric Siegerman
Subject: Re: Autoconf 2.49e
Date: Tue, 24 Apr 2001 14:28:49 -0400
User-agent: Mutt/1.2.5i

On Tue, Apr 24, 2001 at 03:27:39AM -0300, Alexandre Oliva wrote:
> On Apr 23, 2001, Akim Demaille <address@hidden> wrote:
> > Are you referring to a plain
> 
> >         cvs tag autoconf-2_49e
> 
> Yep.  But it's too late now, since other changes have been checked in
> after the snapshot was taken.

The way to do this without any race conditions is to make the tag
*first*.  Something like this:

# (1) Tag the file revisions that will be in the 2.50 release.
        cvs tag autoconf-2_50

# (2) Create a new, temporary sandbox containing the tagged revisions.
        # The -d can take a relative pathname, of course.  Just
        # make sure:
        #   - the named directory doesn't already exist
        #   - you're not creating the new sandbox inside your
        #     current one, which would be confusing
        cvs checkout -r autoconf-2_50 -d /some/where/autoconf-2.50 
wherever/autoconf/lives/in/repository
        cd /some/where/autoconf-2.50

# (3) Create the 2.50 distribution.
        # Because of (1) and (2), you're confident that it's
        # precisely the tagged revision of each file that will be
        # included.
        ...
        make dist
        ...

# (4) Clean up.
        # You can use "cvs release" instead, but there's no
        # point; it writes an entry to the history log, but is
        # otherwise equivalent to this.
        rm -rf /some/where/autoconf-2.50


Instead of creating a temporary sandbox, you could temporarily
switch your development sandbox over, like this:

        # A variant of step (2)
        cd /your/development/sandbox
        cvs update -r autoconf-2_50

        # The corresponding variant of step (4)
        cd /your/development/sandbox
        cvs update -A

But the "checkout" variant is much better.  If your sandbox
contained uncommitted changes (which it won't because you're
careful, but still...), or files that aren't being tracked by CVS
at all (eg. that you forgot to "cvs add"), the "update" variant
would still let them be used when building the distribution,
which would violate the whole point of tagging the release.  By
giving you a pristine sandbox, the "checkout" variant guarantees
that *only* CVS-tracked files, and *precisely* the tagged
revisions of those files, will be used.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)



reply via email to

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