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

Re: svn commit: r10429 - branches/1.1.x/subversion/po

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-07-28 23:34:38 CEST

On Wed, 28 Jul 2004, Max Bowsher wrote:

> Erik Huelsmann wrote:
> >>>> Log:
> >>>> Merge translation updates.
> >>>>
> >>>> Merge trunk revisions
> >>>> r10254,
> >>>> r10282,
> >>>> r10409,
> >>>> r10412,
> >>>> r10415,
> >>>> r10418,
> >>>> r10423,
> >>>> r10426.
> >>>>
> >>>>
> >>> Some of these (the changes to es and sv) include formatting strings and
> >>> require voting per hacking. Maybe this was discussed when you were
> away...
> >>
> >> I thought by that we meant you couldn't change the argument ordering,
> >> add any arguments to a message, or change the types of the arguments.
> >> Not that you couldn't touch something that was used as a format call.
> >> Now if you change a %d to %ld then you'd be violating that. But I don't
> >> think adding:
> >>
> >> +msgid "Unsupported FS loader version (%d) for fsfs"
> >> +msgstr "Aplique RA binariamente incompatible (versión %d) para ra_dav"
> >>
> >> violates thats. Am I missing some case where adding that would be bad?
> >
> > I'd love it to mean that. I think the idea is that the review and voting
> > process should make sure that no strings slip through which do change
> > parameters or parameter ordering.
>
> I think the case illustrated by the above example is perfectly ok to merge.

Ofcourse, isnce it is correct. But that's the case with all correct code
if it qualifies for other reasons.

> Any committer doing .po merges to branches has responsibility to check
> carefully that all the strings to merge really do have no format specifier
> changes.
>
> To help them, we might consider declaring that any revisions with format
> specifier changes *MUST* say so in the log message.
>
Two steps that are easy to miss sometimes and that will introduce a crash.

In HACKING, we require voting for any changes to strings in the C source
and we don't allow % changes at all. The .po rule is relaxed so string
changes (I'm always talking about msgstr strings,msgid is a change to the
C code) that don't touch % codes can be merged without voting. But %
changes require voting, since the format strings aren't validated by the
normal build (because that's non-portable) and they easily introduce
crashes. GNU msgfmt can validate format strings, so it is easy to make
sure they are correct. Still people make mistakes and miss this. (I might
be abnormally sloppy, but you can see a recent commit by me that was just
comment fixes, shortly followed by a follow-up that removed an extra */,
so that the whole tree built again...)

That was the idea when I proposed the change to HACKING some month ago.
Ironically, then, jerenkrantz (I believe) objected saying this rule was
too relaxed. And now, some people want to relax it even more:-)

Hope this clarifies the thinkings behind the current rule.

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 28 23:32:52 2004

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.