Subversion configured for Windows Active Directory HTTPS

From SubversionWiki
Revision as of 17:54, 7 December 2007 by Anneb (talk | contribs) (New page: If you want to set up a subversion server on a windows machine that recognizes users from Microsoft Active Directory and uses secure http (https) to communicate with clients you can use th...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

If you want to set up a subversion server on a windows machine that recognizes users from Microsoft Active Directory and uses secure http (https) to communicate with clients you can use the following setup as a template for your configuration.

Binary files cannot be easily merged. The lock-modify-unlock versioning model seems to be the only appropriate model for these type of files. This description also includes client and server side configuration to accommodate for the lock-modify-unlock model for binary files.

Steps to follow

1) download and install Apache 2.2 + open SSL from www.apache.org Do use Apache 2.2 instead of Apache 2.0 if you want to connect to Active Directory

2) download the apache 2.2 binary compatible version of svn from http://svn.tigris.org

3) copy all dll's and modules (.so files) from subversion/bin directory to the apache2.2 /modules directory

4) copy an existing svn repository or create a new repository COPY: cd "c:\program files\subversion\bin" svnadmin hotcopy //computer/share/subversion/repositories/repo1 c:/subversion/repositories/repo1 CREATE: svnadmin create c:/subversion/repositories/repo1

5) create a authorization file: svn.authz

      1. This file is an example authorization file for svnserve.
      2. Its format is identical to that of mod_authz_svn authorization
      3. files.
      4. As shown below each section defines authorizations for the path and
      5. (optional) repository specified by the section name.
      6. The authorizations follow. An authorization line can refer to a
      7. single user, to a group of users defined in a special [groups]
      8. section, or to anyone using the '*' wildcard. Each definition can
      9. grant read ('r') access, read-write ('rw') access, or no access
      10. ().

[groups] group1 = harry,sally group2 = romeo,julia group3 = sally,julia

[/]

  • = r

@group1 = rw