Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Mar 2002 13:11:52 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Dag-Erling Smorgrav <des@ofug.org>
Cc:        Garance A Drosihn <drosih@rpi.edu>, obrien@FreeBSD.ORG, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG
Subject:   Re: Unmoronify CVS
Message-ID:  <3C8FC098.9F665C4B@mindspring.com>
References:  <Pine.BSF.4.21.0203131055300.70491-100000@InterJet.elischer.org> <xzpsn74gtuj.fsf@flood.ping.uio.no> <20020313113424.B4997@dragon.nuxi.com> <xzpg034gssa.fsf@flood.ping.uio.no> <p05101565b8b56678dd9f@[128.113.24.47]> <xzpy9gwfbiu.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote:
> Garance A Drosihn <drosih@rpi.edu> writes:
> > You can check out from read-only repos, such as cd-rom drives.

-R

> Not if you need to use a tag and the repo doesn't have a val-tags
> file, or the tag isn't listed in it.

How is it possible to get a repository with a tag that's not
in the val-tags file, or that lacks a val-tags file, I guess
is the next question?


> > I know I've done it, but maybe I've only done it on openbsd.
> > There's some option you have to include to 'cvs' so it won't
> > try to write anything to the repository.  (I forget what it
> > is though).
> 
> -R, but it won't help.

It certainly won't help if your val-tags file is corrupted or
deleted.  I still can't figure out how you could get into that
situation, anyway.

In the deleted case, it should fall back (obviously), so there
is definitely room for improvement there; in the corrupt case,
well, whatever corrupted it should be undone so it's not
corrupted.

Maybe we can tyurn this another direction?  What is the purpose
that you feel that val-tags was intended to fulfill, and where
does it fall short?  My personal impression is that it's intended
as a list of tags that are there to allow a quick check against a
cached list.

Given that perspective (if right), then the same argument should
be applied to the fallback situation for ldconfig when the lookup
fails to find what it's looking for in cache.  Modern csh's don't
require a "rehash" for a new command to be found, either... it's
just found by falling back to a search (smart ones update their
cache when this happens).

It seems to me that if the val-tags was advisory rather than
mandatory, it would meet the design goals I personally thought
it had...

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8FC098.9F665C4B>