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...]:[EMAIL PROTECTED]:]/path > >For example, > > :ext;command=/my/path/to/an/ssh/client/program:[EMAIL PROTECTED]:/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. [EMAIL PROTECTED] "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
signature.asc
Description: Digital signature
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
