I can understand the concerns being presented in this thread, but at what
point do you have to ask why you are not just using the Apache option?
Then you could just use your native profiles and passwords.
svnserve was at least somewhat meant to be a simple alternative to Apache,
and that includes the authentication options. Even if the passwords were
stored in a hashed or encrypted format, there would still have to be a way
to tell them to Subversion so that it could hash/encrypt them to begin
with. This either means they still have to be entered by you in clear
text and then some script is run to modify them, or some complicated user
management system has to be written in svnserve to allow the end user to
supply this information, or tie svnserve in with some native platform
authentication system. At that point, I come back to, why not just use
Apache if you have these requirements? At what point does svnserve start
to lose its "simplicity"?
I realize there are reasons why people prefer to use svnserve over Apache,
but when you start talking about wanting to use your native profiles and
passwords and having finer grained authorities it seems like you are then
ignoring all of the benefits that already come with using Apache.
I started out wtih svnserve, but I soon realized that I didn't want to
manage profiles and passwords when my Active Directory already did all of
that, so I just switched to Apache. It was not hard, and I get all of
those features, as well as others "for free".
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 3 17:15:56 2004