Date: Thu, 14 Mar 2002 03:20:23 -0500 (EST) From: Chris BeHanna <behanna@zbzoom.net> To: FreeBSD-Stable <stable@freebsd.org> Subject: Re: /etc/make.conf question Message-ID: <20020314025831.G676-100000@topperwein.dyndns.org> In-Reply-To: <njhenj90z1.enj@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
(Staying on -STABLE 'cause I think this is relevant. I won't drag it
out any longer, though, and I certainly won't get into SCM peeing
contests in this forum.)
On 13 Mar 2002, Gary W. Swearingen wrote:
> Chris BeHanna <behanna@zbzoom.net> writes:
>
> > I cvsup at least twice. If I get no changes the second time, I'm
> > reasonably certain that what I have is not a mid-commit snapshot.
>
> Thanks. That sounds pretty good, except for the judgement involved in
> guessing how long to wait between cvsups. But it should save some
> grief, especially with a slow build computer.
It does indeed. I do the same thing at work when updating a tree
before doing a build prior to a commit.
Yes, there's still a chance that you fell into the middle of a
commit (or a mirror update, as Jeffrey Mountin pointed out), but
the chance is greatly reduced.
I don't try to guess how long to wait between cvsup runs at all.
For me, a complete run of cvsup takes between three and five minutes
(cable modem) when using my nearest mirror. Even if someone is
committing pieces-parts of a larger logical change, that should be
enough time for some new pieces-parts to trickle in. Usually, I'll
get distracted between my cvsup runs anyway (e.g., go get a cup of
coffee, go look at what my son keeps asking me to "Come look!" at,
etc.) which allows several (sometimes several tens of) minutes to
elapse in between iterations. Like many others here, I record the
timestamps at the beginning and end of each cvsup run, so that if I do
have a problem, others have a chance at reproducing it by grabbing the
source tree as of the same point in time that I did.
> Can anyone guess the minutes per day when the cvs is in a bad state
> so that a probablity of this being needed could be guessed at? (I'm
> planning to write a build-SOP PR with this idea for the Handbook,
> with a note stating why some might not want to bother with it.)
A few months ago, I asked if we could have a daily fifteen- to
thirty-minute quiet window on -STABLE such that if a committer wasn't
confident that (s)he could complete the commit prior to the beginning
of the window, (s)he would hold off until the window had passed. Then
everyone around the world could use the -D option in their supfiles to
grab the source tree using a sticky date (this technique doesn't
require you to cvsup during the quiet window. You can wait awhile so
that the mirrors get updated, then grab the source tree as it was
during the window). This doesn't work with bare cvs (which can't
handle -D and -r at the same time: -D forces -r to be the trunk), but
does work just fine with cvsup.
The trouble with this is that there are committers all over the
world in nearly every time zone; therefore, any quiet window you pick
is going to cause someone some inconvenience. Of course, if the quiet
window was scheduled to coincide with that timezone's normal
dinnertime, it might not be so bad.
> > Of course, I don't do this every night, or even every week--that
> > might be a bit abusive to the mirror.
>
> Maybe one of the many people who do this very frequently could
> comment on how much data they download on average, compared to, say,
> once per RELEASE. I've seen no evidence as to whether it's abuse or
> not. (I been cvsup'ing only about every two months.)
Every time you do a cvsup, file checksums on the server are
compared to the file checksums on your disk. There's still quite a
bit of network traffic, but not so much as there would be if you just
grabbed an entire source tree at a time instead of just the deltas.
> > ...(I've heard rumblings about Perforce)...
>
> My dictionary says "perforce" means "willy-nilly".
I'm sure Perforce is a wonderful SCM system--everyone I know who's
used it--bar none--has liked it. It's on the pricey end of the scale,
however, and that makes it problematic for using on a free software
project.
--
Chris BeHanna
Software Engineer (Remove "bogus" before responding.)
behanna@bogus.zbzoom.net
I was raised by a pack of wild corn dogs.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020314025831.G676-100000>