Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Jun 2008 14:58:32 -0700
From:      "David O'Brien" <obrien@freebsd.org>
To:        Peter Wemm <peter@wemm.org>
Cc:        Ian FREISLICH <ianf@clue.co.za>, current@freebsd.org
Subject:   Re: Anyone else seeing this (cvs wierdness)?
Message-ID:  <20080606215832.GA82082@dragon.NUXI.org>
In-Reply-To: <e7db6d980806061024j683e45afj6198f1491e72b691@mail.gmail.com>
References:  <E1Jx0fn-0001OZ-4J@clue.co.za> <20080606155541.GA90949@hub.freebsd.org> <e7db6d980806061024j683e45afj6198f1491e72b691@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 06, 2008 at 10:24:40AM -0700, Peter Wemm wrote:
> On Fri, Jun 6, 2008 at 8:55 AM, David O'Brien <obrien@freebsd.org> wrote:
> > On Fri, May 16, 2008 at 04:12:39PM +0200, Ian FREISLICH wrote:
> >> Recently - I guess in the last month or two - successive cvs updates
> >> always "updates" files in the following directories, this with no
> >> update to the CVS repo:
> >>
> >> cddl/contrib/opensolaris
> >> contrib/ntp
> >> contrib/ipfilter
> >> contrib/expat
> >> contrib/tcsh
> >>
> >> I sync a local CVS repo using cvsup and I update my source using
> >> 'cvs -q update -PdA'
> >
> > Why are you always using "update -A"?  Basically all the reports of
> > weirdness are due to folks not fully understanding what -A does and is
> > for.
> >
> > If -A removes stickly dates, tags, and (what you're seeing here) stickly
> > options.  Options can be set locally, in the ,v file on the server.  Some
> > keywords (such as $Name$) may need to be updated due to "update -A".
> 
> We use -A because we've often messed with sticky dates and tags in our
> checked out copy and want to reset anything we've forgotten and start
..
> This is not what is happening now.  If the server has a nonstandard
> rcs keyword expansion mode, cvs fetches a fresh copy, each and every
> time.  Even if the checked out copy has the correct expansion mode.
> Over and over and over again.

Talk to the CVS developers (and read the bug report trail that lead to
this change).  This behavior is intended.  I'm not saying I care for it,
but its not a bug.

> from a known state.  For the last 14 years, -A has done exactly that.
> If a stray sticky date or sticky tag had been set, -A would reset the
> tag and fetch a new copy and life was good.

Except that it wouldn't do it in all cases where it was needed.

-- 
-- David  (obrien@FreeBSD.org)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080606215832.GA82082>