On Thu, Oct 16, 2008 at 11:26 AM, David Weintraub <qazwart_at_gmail.com> wrote:
> I'd recommend svnmanager too, but that's for http.
>
> The password file in Subversion is a text file, so it shouldn't be too
> difficult to write some sort of script to manage this. This could be
> placed in a web interface via CGI scripting, using PHP, JavaScript, or
> some other mechanism. Heck, it doesn't have to be in the same
> directory as the repository. You can set where this file in your
> svnserve.conf file. The svnserve process doesn't have to have write
> permissions, but does need read permissions.
>
> The real issue is security: If you have a process that allows others
> to update this file, you have the possibility that others can also
> read this file and see other people's passwords. After all, it is in
> clear-text format.
>
> I did this about three years ago back in the Subversion 1.2 days. Took
> me about three to four hours to get a Perl script running via CGI to
> do what I want.
>
> Another possibility is to do this via SASL. This is a new feature of
> Subversion 1.5, so I haven't tried this yet, but it is documented in
> the Subversion book. See <http://peek.snipurl.com/4f272>
> [svnbook_red-bean_com] and <http://snipurl.com/4f280>
> [asg_web_cmu_edu] for more information.
>
> Or, you can use the old standby: svn+ssh:// as your protocol. This can
> be a bit tricky to setup, but it isn't too difficult. The big problem
> is that this works best for Unix sites that use the standard Unix
> security. It could be possible if you use Samba to do this via Windows
> security too, but that gets a little messy.
I just don't like any of the current protocols:
http --> too slow
https --> even more slow, difficult to setup
svn --> insecure, featureless, dull
svn+ssh --> pain in the ***, doesn't play well with TortoiseSVN.
I guess I'll have a look at SASL, not really sure what it is though. I'll
have to read on it.
Received on 2008-10-16 18:32:50 CEST