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

Re: Yet another newbie

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-08-05 16:21:08 CEST

Branko =?iso-8859-2?Q?=C8ibej?= <branko.cibej@hermes.si> writes:
> Anyway, I hope I can contribute in some small way to Subversion. For now,
> I'll take up Mr. Fogel's challenge and dig into the Vdelta/VCDIFF library.
> It looks like an interesting problem with a lot of potential for generating
> some nice code and the required percentage of horrible bugs.

Bravo! Thanks.

> 1) The HACKING file says:
>
> * Signify internal variables by two underscores after the prefix.
> That is, when a symbol must (for technical reasons) reside in the
> global namespace despite not being part of a published interface,
> then use two underscores following the module prefix. For
> example:
>
> svn_fs_get_ver_prop () /* Part of published API. */
> svn_fs__parse_props () /* For internal use only. */
>
> That's fine iff we can guarantee that no symbol containing two consecutive
> underscores will ever be seen by a C++ compiler, a guarantee I think we
> can't safely make. Quoting from the C++ standard, sec 7.4.3.1.2 para 1:
>
> -- Each name that contains a double underscore (__) or
> begins with an underscore followed by an uppercase
> letter (2.11) is reserved to the implementation for any
> use.
>
> IMHO we should find some other way to name private symbols. Perhaps a
> different prefix (e.g., svnp_) would be better for that purpose.

The two underscores are not about preventing name conflicts, they're
about reminding humans that a given object is not part of the
published interface, despite its appearance in a public place.

> 2) This is from subversion/libsvn_subr/svn_parse.c:
>
> apr_status_t
> svn__my_readline (apr_file_t *FILE, svn_string_t *line, apr_pool_t *pool)
> ^^^^
>
> Hmmm... and it indirectly includes <stdio.h>, too ...

Agree, will fix.

> 3) Oh, yes: something seems to be wrong with the CVS repository. I get
> expat_lite twice on checkout, and conflict warnings about .cvsignore,
> even though I haven't modified anything. Perhaps it's due to an empty
> "D" line I get at the end of expat-lite/CVS/Entries, which is really
> weird. I'm using CVS 1.10.3; should I upgrade that?

Yes, upgrade and try again; if you still have the problem, please let
us know.

Thanks,
-Karl
Received on Sat Oct 21 14:36:06 2006

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.