Re: new features for local keywords and keyword expansion

[Mark D. Baushke]

Derek Robert Price <derek@ximbiot.com> writes:

> The documentation looks good, but I have some general comments on the
> idea and implementation:
> 
> Why bother with KeywordExpand at all?  I can understand why someone
> might want to use LocalKeyword, but I'd like a justification for
> KeywordExpand before I decide it's useful.

If you are tracking third-party sources in a repository, many often find
it useful to do the equivalent of -ko to reduce merge conflicts on
subsequent drops of code.

> 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.

> Why bother supporting the tag & tagexpand aliases at all if you're not
> trying to be compatible out of the box with an existing installation?

Good point. I will remove the two aliases.

> Admins are going to need to update their CVSROOT/config anyhow, so why
> pollute the namespace, especially when we already use "tag" to mean
> something else?

Agreed.

> I think you doc'd the wrong name in src/ChangeLog for rcs.c.  You
> mentioned Tag & TagExpand.

Oops. Thanks!

> 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.

> 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.

        Enjoy!
        -- Mark