On 11/1/07, Leonel Gayard <leonel.gayard@gmail.com> wrote:
> Hi all,
>
> I understand that when I use the svn+ssh:// protocol, a new svnserve
> process is launched within the ssh process, and it modifies the file
> in the repository to make commits. Now, is it possible that two users
> may commit via ssh at the same time, thus lauching two svnserve
> processes, and creating race conditions to the repository files, and
> corrupting them ?
No.
> This race condition happens when users access the repository via the
> file:/// protocol, right ?
Wrong. The FSFS repositories use file-locking to protect races from
occuring. BDB uses its own facilities to provide the same guarantees.
> Will it happen via svn+ssh:// too ?
Well, without races in FSFS*, this won't be a problem for any protocol, right?
> I'm trying to switch to a single svnserve daemon process, and removing
> direct access from the users to the repository files. Because it is a
> single process handling every request, it can prevent race conditions.
No: the deamon forks a subprocess to handle every client connection
coming in, resulting in just as many separate processes accessing the
FSFS repository.
> My users are complaining about this change, because the passwd file in
> the configuration files stores plain passwords (e.g. john =john123).
> Instead, we would be much more confortable using hashes of passwords,
> such as htpasswd, or the MD5 or the SHA1 of each password or any
> encryption method.
>
> It this possible ? Can this be done in svnserve ? Does Apache with
> WebDAV allow this ?
Have you searched the archives regarding our password problems and
alternatives? There have been numerous threads explaining why things
are as they are, but with my comments above, I'd say you can safely
revert back to svn+ssh://.
bye,
Erik.
* For FSFS to work on a network filesystem, this filesystem is
explicitly required to support file-level locking. Meaning you'll need
a lockd deamon when using it with NFS.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 1 20:25:48 2007