On Mon, Sep 13, 2010 at 7:19 AM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > > On Sep 13, 2010, at 06:05, Zvika Haramaty wrote: > >> Problem: >> • We’re using large components, each built of dozens of SVN >> repositories. >> • Checking out such a component can take 6 hours (we call this >> operation ‘populate’). >> • I.e., we want the populate to be as much automatic as possible. >> • Our IT department requires us to change password every few months. >> • Every time the password is changed, the populate procedure stops for >> several times, requesting for the new password. >> • Of course, there is local caching for ‘known password’s. However, >> updating password is a nightmare. >> >> Possible solution: >> • The password can be saved to a special environment setting (e.g. >> SVN_PASSWORD) >> • The password can be stored in the ~/.subversiom/.auto directory - >> Not caching after user has written the password; but storing the password >> beforehand. > > Have you considered using Subversion's existing --username, --password and > --no-auth-cache arguments?
Storing the clear-text user passwords in ~/.subversion/.auto is *BAD, BAD, BAD, BAD* practice. Storing cleartext passwords would get people fired in every company I've set up subversion for, as a major security violation. And in fact, this does nothing to help that when the password changes. Have you considered switching to a dedicated Subversion user to manage the repository and using ssh+svn with SSH public keys, to avoid these password management issues? It requires some infrastructure to manage the keys, and there is still no well-publicized tool to do this, but it's workable. Or depending on your repository security requirements, what about non-secured read-only access to a central mirrored working copy to first duplicate the working copy, then doing "svn update" on it to bring it up to date? This is especially useful for CIFS users, since checking out a 1 Gig working copy to CIFS shares takes roughly 30 minutes in my experience, while simply duplicating the working copy takes about 3 minutes. This might save you a *lot* of time if that 6 hours is a checkout to a CIFS share.
