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

Re: svn commit: r12837 - in trunk: doc/book/book subversion/clients/cmdline tools/client-side

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-01-25 21:00:58 CET

On Tue, 25 Jan 2005, Julian Foad wrote:

> Peter N. Lundblad wrote:
> > On Mon, 24 Jan 2005 julianfoad@tigris.org wrote:
> [...]
> >>+ svn_xml_make_open_tag (&sb, pool, svn_xml_protect_pcdata, "commit",
> >>+ "revision",
> >>+ apr_psprintf (pool, "%" SVN_REVNUM_T_FMT,
> >
> > We use %ld everywhere else, so why not here?
> Hmm. You're pretty much right - tho only other places where we use it are in:
> contrib/client-side/svn-push/svn-push.c
> subversion/bindings/java/javahl/native/*.cpp (3 places)
> subversion/svnadmin/main.c
Then I missed those few places in when I did this last spring. They should
be changed as well.

> I believe the reason for not using it is because the localisation/translation
> utility can't parse the macro substitution and string concatenation that
> results from usage like:
> _("English text %" SVN_REVNUM_T_FMT " string continues").
That's exactly the reason we did it.

> However, in this instance, the string is not one that needs to be translated.
> Do we wish to deprecate SVN_REVNUM_T_FMT? If not, I think we should continue
> to use it where we can, though I will admit that the benefit of using it is
> vastly diminished if it is only used in a few places.
We didn't want to deprecate it since others might want to use it and there
is nothing wrong with it. In our own code we should just stick to %ld. We
gain nothing by using the longer form. We can't easily change the type
from long int anyway. So I think using it in a few places is just

> Thanks for the review.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 25 21:01:35 2005

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.