Re: svn commit: r11750 - branches/locking/subversion/include

Greg Hudson <ghudson@MIT.EDU> writes:
> Not true. If you turn out to be right all along, we create the user
> type, add svn_fs_set_user(), and change the deprecated
> svn_fs_set_username() to create a user object with no group information
> and set that.

I suspect Branko is probably right, that we will one day need an
opaque type instead of a 'char *'. That doesn't seem like a very
risky projection.

But it still makes more sense now to just use 'char *' username. As
Greg points out, the API tweak is simple when the time comes: we'll
add a new set_user() function, deprecate the old set_username() and
turn it into a trivial wrapper around set_user().

Many applications will only have a username to work with anyway, and
the set_username() function may be all they need, in which case we can
simply refrain from deprecating it, to keep everyone's lives simple.

Thus no matter how we cut it, it seems like the best course is to go
with 'char *' now.

Branko, do you still object?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 18:48:51 2004