On Mon, Sep 13, 2010 at 7:19 AM, Ryan Schmidt
<subversion-2010b_at_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.
Received on 2010-09-13 13:59:48 CEST