[Top][All Lists]

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

Re: commitlog

From: Brian Murphy
Subject: Re: commitlog
Date: Wed, 13 Aug 2003 14:20:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529

Mark D. Baushke wrote:

Brian Murphy <brian@murphy.dk> writes:

Mark D. Baushke wrote:

Anthon van der Neut <AvanderNeut@pinnaclesys.com> writes:

This is against, 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);

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:


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


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

I think this is a bit ambitious - try seeing what happens when you run "cvs up"
in a directory with a filename containing carriage returns:

from bash:
$ touch $'a\nb'
$ cvs up
? a
unrecognized request `b'

Spaces on the other hand are reasonably easy to handle in that they already work
except for problems quoting when external programs are called.


reply via email to

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