info-cvs
[Top][All Lists]
Advanced

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

Re: Debian patches


From: Derek Robert Price
Subject: Re: Debian patches
Date: Thu, 13 May 2004 14:05:48 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What Mark said, to the items I'm not commenting on...

Mark D. Baushke wrote:

> >#1: cvs.1 doesn't mention annotate
> >==================================
>
>http://www.einval.com/~steve/software/debian/cvs/patches/01_man_annotate.patch
>
> >Obvious...
>
> I believe that Derek has moved to autogeneration of cvs.1, but I have
> not yet looked closely enough at the new technique to determine how to
> implement your current patch on the new doc/cvs.1 file rhat replaces the
> man/cvs.1 file.


Yes.  Basically, the "Guide to CVS commands" appendix of the manual is
being converted pretty directly from the cvs.texinfo file, with some
header and footer text tacked on.  Any corrections to the new man
pages (to be released in 1.11.16 & 1.12.8) should be to the
cvs.texinfo file instead.

> >#4: Newlines in checkin template
> >================================
>
>http://www.einval.com/~steve/software/debian/cvs/patches/04_newlines_in_commit_template.patch
>
> >Clean up newline-handling slightly when editing commit messages.
>
> I seem to recall getting shot down when I tried to add these newlines
> back into cvs a while ago. The thought was that you could put what you
> wanted into the rcsinfo template you are using...


Yep.

> >#5: Alphanumerics in keywords
> >=============================
>
>http://www.einval.com/~steve/software/debian/cvs/patches/05_keyword_alphanumerics.patch
>
> >It's useful to have alphanumerics rather than just alphabetics in
> >custom keywords (consider XFree86)...
>
> I have no strong feelings about this patch, it seems reasonable, but
> what do other folks think of it?


I have no strong opinion either.

> >#6: Extra *info substitutions
> >=============================
>
>http://www.einval.com/~steve/software/debian/cvs/patches/06_extra_info_subs.patch
>
> >This is old stuff which is superseded by the *info changes in 1.12.6
> >onwards, but these are currently used. I've updated so they should
> >work with 1.12.7:
>
> >%S for filename enclosed in quotes - essential if you're going to try
> >   and parse filenames with spaces in using old-format info


Filenames are always quoted with the new *info stuff, there is no
reason for adding this format specifier.

> >%T for tag


I'd rather you go with %t for consistency with the taginfo format
specifier.

> >The %S is needed for the CVS-bugzilla integration stuff I've
> >documented at http://www.einval.com/~steve/software/cvs-bugzilla/
>
> This change needs documentation and sanity.sh test cases before it
> can be adopted.


Yep, the %t change would need tests & doc.  The %S change is unnecessary.

> >#7: More PAM work
> >=================
>
>http://www.einval.com/~steve/software/debian/cvs/patches/07_PAM_changes.patch
>
> >Updates for PAM:
>
> >Add PamAuth and DefaultPamUser keywords to control PAM auth
>
> >PamAuth and SystemAuth can then be used for fine-grained control over
> >authentication.
>
> Hmmm... I have no opinion on this one other than that I am not a fan of
> having cvs support PAM in the first place...


Me either.

Anyhow, glancing at your patch, it seems to me that it's a lot of
unnecessarily PAM-specific overhead.

First of all, if the executable is compiled with PAM then it seems to
me that authentication should alway be configured via the PAM
configuration.  If you want "system" authentication, then it should be
configured there.  CVS should not me making the distinction!  This
decision was made at compile time!

Secondly, any fallback user should be more general.  It should also
work for gserver, kserver, & pserver.

> >#9: -l still causing problems
> >=============================
>
>http://www.einval.com/~steve/software/debian/cvs/patches/09_noop_-l.patch
>
> >-l was re-added on the server, but can still cause client end
> >problems. I've re-added it for the client too; it's simply a no-op at
> >the moment.
>
> Yeah, I am not sure what to really do about the -l switch these days.


What problems, specifically, does a client not accepting -l cause?

Derek
- --
                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAo7j7LD1OTBfyMaQRAh2wAKDxe1JO3+HQ9FREaUQIISyAOtIPwACg+lB0
9qC2FTt5PJgFRluMdY8GNxA=
=WVlx
-----END PGP SIGNATURE-----





reply via email to

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