[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: utf-8 sanity check.

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2002-07-12 00:53:33 CEST

I don't know if anyone remembers this, but the reason for the --locale switch
was to make the OUTPUT of svn use the given locale. Branko wanted to add that
feature to make programs that parsed svn output have a reliable way to ensure
that svn would be generating output in the format that they expect.

On Thu, Jul 11, 2002 at 03:51:22PM -0700, Greg Stein wrote:
> On Thu, Jul 11, 2002 at 05:16:49PM -0500, Karl Fogel wrote:
> > Greg Stein <gstein@lyra.org> writes:
> > > Not at all. The Python test can easily set the appropriate locale environ
> > > variable before executing the test process (the exec*e functions).
> > >
> > > $ svn --locale=FOO status
> > > $ LC_CTYPE=FOO svn status
> > >
> > > They're the same number of characters, so don't even try to say "well, it is
> > > easier to type". Why are we writing code for this? The system environment
> > > variable is the defined way to handle this stuff. Why invent something new?
> > >
> > > IMO, it was a mistake to put in initially, and a mistake to retain/fix.
> >
> > As long as we have a way of doing this in environment, at run time, on
> > all supported platforms, then I'm +1 on removing the option as well.
>
> I think you're overstating the level of the requirement. I've seen two
> stated use cases for the --locale switch:
>
> 1) your log message is not in the system locale
>
> 2) your working copy is not in the system locale
>
> I find the second case "bogus" (I can't think of a less connotative word).
> If your WC isn't using the system locale, then *what* other programs are
> going to work well with it?
>
> Exercise for the reader: name one other program with a --locale switch,
> which somebody might be using with that WC. (heck, name one period)
>
>
> The first option (the log message) is about the only thing that I (barely)
> can see as a true use case. So now your requirement can be rewritten as:
>
> "As long as we have a way of supporting a log message in any charset, on
> all supported platforms, then ..."
>
> Now how many people will actually be doing that? Karl, you've used yourself
> as an example of writing in Big-5, yet your system locale is (presumably)
> ISO-8859-1. But are you truly a typical user? Will your log messages really
> be different?
>
> And if we're only talking about the log message, then shouldn't the switch
> be --locale-message ?
>
> > But
> >
> > $ LC_CTYPE=FOO svn status
> >
> > will not work on non-Unix, and won't necessarily even work in all Unix
> > shells, right? Not saying that's a showstopper, just want to know
> > what the right solution *is* for those other situations...
>
> $ env LC_CTYPE=FOO svn status
>
> will work on all shells. For the Windows case, I still question the utility.
> I *really* feel that we're catering to a fringe case that actually won't be
> used. I think the --locale switch was added before we knew what it should be
> used for, and now we're just compensating. It seems that we are taking its
> presence as a statement of need, rather than considering the option of
> simply removing the thing.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • application/pgp-signature attachment: stored
Received on Fri Jul 12 00:56:45 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.