On Nov 11, 2005, at 20:21, Gale, David wrote:
> b)I haven't seen it discussed, and have been monitoring the list for a
> while; this isn't merge tracking, which comes up at least once a week.
> Yes, I could probably revive a months-old thread by searching through
> the archive, but that seems like it'd be silly.
> c)You actually make a pretty good argument *in favor* of adding a tool
> specifically for svnserve'd repositories. Every other access method
> either doesn't have passwords (file:///), or has tools available that
> allow users to change their own passwords, as you point out; it's
> trivial to expect administrators to install these tools. However, for
> svnserve, there isn't a tool to be installed--the administrator would
> need to create one, which is far less trivial. As I read the book,
> svnserve is supposed to be a perfectly acceptable equivalent to
> http[s]://, but it is the only method that requires the
> administrator to
> create a new tool from scratch (or else manually maintain the file).
> With the passwords in plain text, this isn't too hard for anyone _who
> knows how to program_, but it's very possible that the repository
> administrator is not a programmer. (Changing to encrypted passwords
> would probably entail the creation of a server-side tool, so the
> client-side tool could just call that, conceivably; this would
> actually
> make creating such a tool easier, though still not something for a
> non-programmer.) And, of course, if the team uses multiple OS's, the
> tool would need to be available on each OS, which is beyond the
> scope of
> most casual programmers. (It can't be simply a web page, because many
> servers only have the command line available.) And I haven't even
> mentioned that the tool would need to speak the svn protocol, in case
> the server is behind a restrictive firewall. Or figuring out how to
> authenticate users before changing their password, especially once/if
> the passwords are stored in encrypted form. The subversion client
> already has the necessary framework in place.
>
> As to the fact that this would be creating a part of the subversion
> client that only works for one specific access protocol out of the
> several available: this is true, but I'm not really sure how it can be
> viewed as a valid argument against it. It'd be trivial to check the
> access method and spit out an error message immediately for anything
> other than svn. There're already parts of subversion that are
> option-specific (for instance, "svnadmin list-unused-dblogs" doesn't
> work on FSFS repositories), so it's not breaking any precedents. And,
> finally, svnserve is "a custom server" (quoting the book); expecting
> third parties to further customize it to provide such basic
> functionality is, well, a bit odd, frankly.
>
> Having said all of that, I'd be interested in hearing any arguments
> why
> the subversion client should not have a tool for changing user's
> passwords for svnserve'd repositories, or why proposing such a tool is
> "getting carried away".
You've obviously thought about the problem much more than I have. You
make some compelling arguments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Nov 13 17:54:55 2005