Re: svn commit: rev 1563 - trunk/subversion/include trunk/subversion/libsvn_subr trunk/subversion/clients/cmdline trunk/subversion/libsvn_ra_dav

Karl Fogel wrote:

>Branko Čibej <brane@xbc.nu> writes:
>
>>I don't understand this change at all. Why do you want to *create* the
>>~/.subversion dir? It's not as if we'll store any state there, we just
>>read stuff if it happens to be there.
>>
>
>So it's easy for people to learn how to use it (same thing we do with
>the FS config files).
>
>If the dir exists, with example files and a README, then telling
>someone how to use proxies is as simple as "Go look in your
>~/.subversion/ dir and let us know if you have any questions."
>
Oh, well. I dislike creating stuff in the user's home in lieu of
documentation ... -0

>>Why? This way you throw away the known length of the string, for no benefit.
>>
>
>The benefit is not having to clutter other code with stringbufs. APIs
>that demand stringbufs when null-terminated strings would do just as
>well place a burden on their callers. That's why we've been getting
>rid of stringbufs all over the place lately.
>
Um. They weren't stringbufs, they were string_t's. There's a difference
-- no allocations, for one thing.

>Is there some reason we need the length of the string? It's not
>binary data, after all.
>
The *user* of the code may need it, to avoid strlens. I thought that's
what svn_string_t was for.

Sure, kill the stringbufs where they're not needed, but string_t's are
useful, imho, and quite as easy to use as plain pointers.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org