info-cvs
[Top][All Lists]
Advanced

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

Re: Debian patches


From: Steve McIntyre
Subject: Re: Debian patches
Date: Thu, 13 May 2004 13:36:28 +0100
User-agent: Mutt/1.5.5.1+cvs20040105i

On Thu, May 13, 2004 at 02:28:16AM -0700, Mark D. Baushke wrote:
>
>> I've been a little remiss with the patches we apply for the Debian
>> packaging and I've forgotten to send some of them on. Some may not be
>> to everybody's taste, but some are obviously correct and
>> useful. Here's the first batch. All should apply against 1.12.7. I
>> tried posting these to bug-cvs on Sunday evening, but they never
>> appeared. Neither did the other mails I sent to bug-cvs that night. In
>> case attaching the patches caused the problem on the list, here are
>> links to the patches online.
>> 
>> #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.

Cool. I'll have a look myself. Is that in ccvs now?

>> #2: cvs.texinfo cleanup
>> =======================
>> http://www.einval.com/~steve/software/debian/cvs/patches/02_info_docs.patch
>> 
>> Minor fixes to cvs.texinfo.
>
>This one looks okay. I will commit this change after I get some sleep
>unless someone else beats me to it.

Cool.

>> #3: allow :ext=<foo>
>> ====================
>> http://www.einval.com/~steve/software/debian/cvs/patches/03_ext_expansion.patch
>> 
>> Simple patch. Rather than have to set CVS_RSH in the environment,
>> allow the CVSROOT to specify the ext method also.
>
>This is being handled in many different and mutually exclusive ways.
>I suspect we are more likely to go to a :ext;command=foo: direction
>of the CvsNT folks with a format like:
>
>    :ext[{program}][;command=value...]:address@hidden:]/path
>
>For example,
>
>    
> :ext;command=/my/path/to/an/ssh/client/program:address@hidden:/path/to/CVSROOT
>
>see the method options processing in the root.c::parse_cvsroot()
>function in top-of-tree cvs.cvshome.org for an example of what is
>possible...

Aha! That looks excellent. Another wishlist bug against the Debian
packages is a way of passing arguments to the CVS_RSH program, e.g. to
specify a port number. Adding that may be tricky...

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

True, but lots of people don't use templates. It would be nice for the
default blank message to be easier to use.

>> #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?
>
>> #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
>> %T for tag
>> 
>> 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.

Agreed. I've added these mainly for my own use for now, and I'm
planning on migrating the changes over to simple uses of the new *info
code soon.

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

Yes, I'd noticed. :-)

>> #8: Cope with leading whitespace in ~/.cvsrc
>> ============================================
>> http://www.einval.com/~steve/software/debian/cvs/patches/08_cvsrc_whitespace.patch
>> Obvious and useful, I'd hope...
>
>Hmmm... test cases for sanity.sh are be greatly desired for even this
>kind of simple change.

I'll have a look.

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

People were scared by the change, so it was easiest to add a no-op.

-- 
Steve McIntyre, Cambridge, UK.                                address@hidden
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Attachment: signature.asc
Description: Digital signature


reply via email to

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