Re: CVS_USER

[Derek R. Price]

Jim Kingdon wrote:

> I'd like to propose checking in the patch at
>
>   http://www.cvshome.org/cyclic/cvs/dev-user.txt
>
> There is lots more discussion at
>
>   http://www.cvshome.org/cyclic/cvs/dev-user2.txt
>
> My summary/reaction is that setting CVS_USER in the environment is the
> way to provide the cvs username.  And the dev-user.txt patch is a good
> enough way to do that.

You'll have to include a ChangeLog entry and sanity.sh test case.

Okay, sorry.  I've always wanted to say that.  Seriously:

I've no objections, but a few comments/questions.  Quotes are from
http://www.cvshome.org/cyclic/cvs/dev-user.txt .


1)  I've no current objection.  It's actually redundant with some of the
stuff in my *info patch (%u for CVS username becomes ubiquitous when
calling scripts from *info files), but I'm not ready to check that in
yet.  I was hoping for some discussion and perhaps comments and I've been
too busy to do the evangelizing myself.


2)
> Another example is that regular expressions are not a convenient
> way to specify particular directories/files.  Like I said, I'm not
> expressing an opinion about whether this should be dealt with at
> the same time as the environment variable versus internal variable
> thing.

Why not?

    ^dir1/dir2/filename.ext$

could fully specify a particular file if CVS ever tried to match by
filename and

    ^dir1/dir2\(/\|$\)

fully specifies a directory and all subdirectories under the current
design.  Granted, regular expressions can appear cryptic but they allow
the flexibility to allow an admin to design and use namespaces or operate
differently dependant on file extensions.

3)
> Write up a design for communicating information to server
> plug-ins.  This might be just a relatively straightforward change
> to put the internal variables and user variables back into
> environment variables, or it might be more far-reaching (CGI and
> FastCGI are successful examples of plug-in interfaces which are
> far more clean than what CVS has).  Circulate such design(s) and
> see what people think.
>
> I will mention one particularly thorny issue: how to try to make
> the interface portable beyond unix.  I don't really know what the
> deal is in terms of CGI versus WinCGI versus whatever on Windows,
> for example.  It might end up being desirable to mostly punt this
> issue, I don't know.

Does anybody have a more current opinion on this?  Jim, has your opinion
changed?  I'm going to research some myself but thought asking might be
quicker.  Is there a current, more portable standard?  What's being done
with XML?  What's wrong with my *info design (loosely based on loginfo's
format strings), aside from the weaknesses involved in passing multiple
lists?  Is handling multiple lists important for CVS?  I thought not, as
CVS usually only passes a list of files (or tags) and possibly some
associated revisions or status and I don't see any immediate reason to
want to pass any more than that.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
In my day, we didn't have virtual reality. If a one-eyed razorback
barbarian warrior was chasing you with an ax, you just had to hope
you could outrun him.

        - Sarah M. Wolford, Hanover in a Washington Post contest