bug-cvs
[Top][All Lists]
Advanced

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

Re: commitlog


From: Mark D. Baushke
Subject: Re: commitlog
Date: Wed, 13 Aug 2003 01:10:41 -0700

Brian Murphy <brian@murphy.dk> writes:

> Mark D. Baushke wrote:
> 
> >Anthon van der Neut <AvanderNeut@pinnaclesys.com> writes:
> >
> >
> >>This is against 1.12.1.1, I am trying to get it make it in the official
> >>release, so I can stop worrying to break or processing on each upgrade of
> >>the servers. Comments and critique are welcome, pointers on who to ask to
> >>apply this patch as well.
> >>
> >>diff -u -r1.70 logmsg.c
> >>--- logmsg.c    23 Jul 2003 20:42:26 -0000      1.70
> >>+++ logmsg.c    13 Aug 2003 03:58:53 -0000
> >>@@ -882,6 +882,9 @@
> >>        cp += fmt_percent - filter;
> >>        *cp++ = '"';
> >>        cp = shell_escape (cp, srepos);
> >>+       cp++ = '"';
> >>+       cp++ = ' ';
> >>+       cp++ = '"';
> >>        cp = shell_escape (cp, str_list);
> >>        *cp++ = '"';
> >>        (void) strcpy (cp, fmt_continue);
> >>
> >>Regards
> >>Anthon
> 
> I sent this patch a long time ago to fix the same problem but even
> though I begged I got no comments ;-).

Yeah, that happens sometimes... last November was busy for me, so I
think I somehow missed your message.

> I pass the repository name and each item generated from %{...}
> as a seperate argument:
> 
> http://mail.gnu.org/archive/html/bug-cvs/2002-11/msg00092.html
> 
> I think the argument against such things is that it will break already
> running scripts. Perhaps a command line argument should signal the
> new format?

More likely a CVSROOT/config option or a different %{...} token would be
the right approach. That would allow script writers to do the right kind
of interpretation of the command-line arguments they get on their
scripts.

Possibilities:

    - Use a NUL byte to separate token elements, a la GNU find's -print0
      switch and xargs -0 switch and GNU textutils 'sort -z' option.

    - Possibly go to a quoting mechanism such as is used for URLs. With
      % being an escape for hexadecimal bytes. So, %20 is a space.

I have not really thought thru the implications of such a change, but it
would be useful to be able to handle all of the possible Unicode
characters that some filesystems are starting to use in filenames under
some operating systems.

        -- Mark





reply via email to

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