bug-cvs
[Top][All Lists]
Advanced

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

Re: new features for local keywords and keyword expansion


From: Derek Robert Price
Subject: Re: new features for local keywords and keyword expansion
Date: Tue, 10 Jun 2003 09:40:43 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Mark D. Baushke wrote:

Derek Robert Price <derek@ximbiot.com> writes:
It would be cooler if CVSHeader included the _real_ CVSROOT from the
last checking rather than just stripping the path portion.  In other
words, gather it from the client, :pserver: or whatever string and
all. Wouldn't that be more useful if someone handed you a bug report
from an application with this Id string?  Of course that would require
client mods...

Hmmm... the CVSHeader is intended to be the relative pathname for a
given file from the CVSROOT.

If you look at things like the various NetBSD, FreeBSD and OpenBSD
mirrors, you may be doing updates from one or the other of them if a
given one is down. often the pathname to the repository differs between
mirrors, so you really only want the module name in the keyword that is
getting expanded. It is typical in the *BSD world to do updates of your
tree from one or more different mirrors over time before doing a final
update from the master and a commit to the master. Avoiding odd
conflicts is a good idea.

So, someone does a checkout from the closest *BSD mirror, does their
work and then eventually does a 'cvs -d :ext:user@master.repository.org
update' with the -d option pointing to the master repository and then
conflict resolution, build and commit to the same master. Then their
mirror gets updated via CVSup sometime a bit later.


Okay, that makes sense. I was thinking along the lines of someone forking your distribution, or at least maintaining a variant. Then when you got a bug report you could see the differing repository & perhaps even direct people to the correct place to file a bug report. Not a big deal, though. Maybe I'll keep it in mind for a CVSROOT keyword, or the like, for later.

This would also be cooler if this could be configured by project, at
least with KeywordExpand.  I don't think I'd like having to turn off
the Header keyword for an entire repository if I only wanted to
disable it for my local import of FreeBSD or whatever, but I'm neither
going to do the work myself nor protest its inclusion on these
grounds.

Hmmm... most of the time I have seen this used were for special-purpose
repositories. I had not considered trying to make it work on a per cvs
module basis.


This is mainly why I wouldn't object. My workaround for complainers would be to tell them to set up a special-purpose repository. :)

Of course, personally, I'd probably use the option to disable keywords
entirely for all local projects, but that's just my personal
preference. ;) Hrm... how about an "all" keyword with "e"? Or does
"KeywordExpand=i" do the trick?

"KeywordExpand=i" should disable all keyword expansion. I can add a test
for this if you wish.

Is it likely to break?

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
--
My karma ran over my dogma.







reply via email to

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