I'll work on filing issues for some of this stuff in a bit.
On Sun, 2002-11-03 at 18:22, Greg Stein wrote:
> Hmm. Did we come to a resolution on the on this? Seems there was still some
> open discussion on whether this would excessively bulk up the non-debug
> builds.
Well, there are 736 instances of svn_error_create in our code base. At
16 bytes per __FILE__ instance, that's about 12K. And that's if you can
find a compiler which doesn't collapse string literals.
> > ra_dav and ra_local have separate implementations of split_url.
>
> Hmm? I don't see a split_url in ra_dav.
I meant mod_dav_svn, which has dav_svn_split_uri(). They don't behave
exactly the same (they combine some hostname verification with the
repository search), but I'm thinking there should be an
svn_repos_find_repository() which accepts a pathname and returns a
repository and fs_path.
> I recall some part of the RA interface being very relaxed about empty
> strings versus NULL points. Something dealing with the authors and dates and
> stuff. I certainly have no problem tightening up stuff like that.
Right now, we don't generally assume that a revision has an author or
date; in practice, revision 0 doesn't have them any all other revisions
do. We might be able to clean this situation up by doing something
intelligent with revision 0 and treating it as a database corruption
error if any other revision doesn't have commit info.
> >...
> > svn_path_basename()'s contract could be to return a pointer into the
> > argument string, instead of duplicating the result into a pool
> > argument. This would make some code simpler.
>
> I thought about this, but the caller would never know if the passed-in
> string is part of the output or not. Today, the caller can change the input
> string at will since the contract says the result will always be a new
> string in the provided pool. (the doc specifically states it will make a
> copy, even when it isn't strictly necessary)
Oh, my idea was that the output would always be part of the passed-in
string (unless the output is "", maybe), and the caller could
apr_pstrdup the output if it wanted to change the input string.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 4 19:25:09 2002