Weighing setup factors for subversion

Question

I have a number of different projects, about 5, and a number of different developers, around 15, and some of the projects are in subversion and some are not. All of the developers are working on windows-based machines with TortoiseSVN, and the code of the projects is a mish-mash of classic asp, and asp.net. What is the best, as in most responsive, useful, and easy to administer, way to have all of the projects under subversion and have authenticated access for all of the developers, both read and write?

Some of the things to consider would be to serve it out via svnserve or apache, which means there are speed concerns, ease of administering access/users & passwords, and the need to open an additional firewall port(if svnserve)

Also to consider are benefits/disadvantages to having multiple projects in one repository vs. one project per repository. The revision disparity isn't much of an issue, but excessive time to get the log might be if multiple projects are in one repository, however, is this offset by easier user administration?

Answer 1

There are only two secure ways that I can think of: Use svn by way of an SSH tunnel, or use svn to pull/push via SSL-enabled HTTP via a Web server.

I'd keep each project in its own repository, using the standard trunk/branches/tags format for each project as the repository layout. It's a cleaner layout since each thing has its own container, and if one of the Subversion databases gets corrupt or wedged, it doesn't affect all work on all projects.

Answer 2

If you're all on relatively speedy lines, running SVN through Apache 2 with SSL is a great option. No firewall hassle and user authentication can be done through several methods.

I have a hosted SVN account on another continent, because of SSL it's not that fast but acceptable, since it's source code we're talking about, not too much data transfer going on. If you have a closer server, I'm sure the performance will be quite ok.

Multiple repositories: I would say configuration issues are worse than possible performance problems. By keeping just one repository, you minimize configuration.

Answer 3

• I would recommend using one repository for all of your projects. It makes setting up access for your developers much easier. Plus you then only have to backup a single repository. Not only that, but it also enables you to easily copy files (and maintain the history of those files) between projects. This probably won't happen that often, but it makes it nice when it does. Creating new projects is then as simple as 'svn mkdir'.

And you don't really lose much by using a single repository. You can still configure access permissions to each project however you like.

Your svn directory structure could look like the following:

projects/
    proj1/
        trunk/
        branches/
        tags/
    proj2/
        trunk/
        branches/
        tags/
    ...

• How big are your projects? Using svn over HTTPS works very well, especially if your network connection is fast. HTTPS is also a fairly universal access system. Unless you are constantly checking out hundreds or thousands of files (or unless you are trying to run blame on a file with thousands of revisions) the speed difference might not be worth it to you. At our company we use svnserve and authenticate with kerberos tickets, but this is a lot harder to setup.

Answer 4

I would recommend

1. Apache, not svnserve-- it's fast enough, firewall- and proxy-friendly, and the user admin is the same work either way. I also find it quite useful to be able to browse my repositories with a browser.

2. Only one repository, with a folder for each project containing trunk/branches/tags. This is a lot more flexible than I thought at first, and in many cases you don't need the subdirectories for trunk/branches/tags. It's way easier to manage a single repository, and you have version control so you don't need to worry about users messing up others' projects or anything.

Answer 5

Multiple Projects vs Single Project:

If the code is common and files will move about, use one repository. If the code is isolated, use many. Remember that:

1. A single repository makes file moving & directory renaming easy and controlled
2. A change in a repository bumps the revision number everywhere in that repository
3. The developer physical directory structure can be different to the svn structure

Authentication

Use apache, and SSL is not needed if you configure apache to authenticate always.

<Location /svn/test>
    DAV svn
    SVNPath /svn/test
    <LimitExcept GET PROPFIND OPTIONS REPORT>
       AuthType Basic
       AuthName "Authorization Realm"
       AuthUserFile /svn/passwd
       Require valid-user
    </LimitExcept>
</Location>

You can play with these rules to require a password on checkout or not. And your passwords live in that one file /svn/passwd.

And...

Use trac as well. It integrates nicely with subversion and gives developers an interface away from subversion to look at their files/changesets etc.