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

Re: [PATCH] SVN_REVFMT_T -> svn_revnum_to_cstring (fwd)

From: Peter N. Lundblad <lundblad_at_softhome.net>
Date: 2004-05-08 21:13:05 CEST

[This was meant for the list too. Sorry.]

---------- Forwarded message ----------
Date: Sat, 8 May 2004 21:05:38 +0200 (CEST)
From: Peter N. Lundblad <lundblad@softhome.net>
To: "[UTF-8] Branko Ä^Libej" <brane@xbc.nu>
Subject: Re: [PATCH] SVN_REVFMT_T -> svn_revnum_to_cstring

On Sat, 8 May 2004, [UTF-8] Branko Ä^Libej wrote:

> Peter N. Lundblad wrote:
>
> >Hi,
> >
> >Attached is a little one that turns most uses of SVN_REVNUM_T_FMT into %s
> >and calls to svn_revnum_to_cstring in *printf functions. Mostly it is
> >error messages and other user messages that I've touched. I haven't
> >modified things that aren't supposed to be localized later.
> >
> >
> Let's all take a deep breath now. The more I look at these patches, the
> more horrible they seem. svn_revnum_t is typedefed to "long int", and
> SVN_REVNUM_T_FMT is %ld. If we don't intend to change that (and
> obviously we don't, in the forseeable future) then all of these changes
> are nonsense and needless complication. Let's just use %ld and be done
> with it.
>
I agree that it is probably unnecessary indirection. I thought the
consensus was to keep SVN_REVNUM_T_FMT (implying that some form of my patch is
necessary), however.

Please, consensus on this matter would be useful before I spend more time
on this patch (and possibly start another boring walkthrough replacing
SVN_REVNUM_T_FMT with something...

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 8 21:03:41 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.