Work in progress

I'd really like to discuss working against the trunk versus per-developer branches with you if we can find the time.

Can you give us some more information about the problem you're having with Apache? Is it an issue with running the Rails app, of is that about the Subversion repository?

On trunk vs branches certainly we can discuss that. I think I'm in the minority in my team on this opinion and haven't thought it through fully, I just know it didn't sit well with me for this project.

Regarding Apache it's not a Rails issue. Our Apache Subversion repository serves repositories on /repositories/ but these are basic auth protected meaning that the public cannot access them without using a guest or public account and password. To make it more friendly to the public some repositories are also exposed at /view/ URLs but for some reason I haven't worked out yet these are not accepting DAV requests. Even though the PROPFIND request type is allowed it gives error 501 Not implemented when attempting to checkout.

There are differences between the /repositories/ and /view/ URLs such as HTTPS vs HTTP (separate virtual hosts) and basic auth vs no auth and no method limit vs limit except GET PROPFIND OPTIONS REPORT but even reproducing the exact same config as the one that works for /repositories/ doesn't help.

Since I can't sleep I figured I'd follow up on your request for discussion of branching practices. Warning: half asleep, I'm rambling :)

I've been putting my thoughts together recently as a list of the differences/pros and cons but it's not a black and white argument and in either approach a healthy amount of common sense is required. The Subversion book has a discussion of feature branches which mentions the key points.

Continuous integration is less useful when making heavy use of feature branches because branches are not tested by continuous integration until merged to the trunk. However, since this only happens when there is something ready for merging feature branches avoid testing something known to be potentially broken. Also, continuous integration is no substitute for developer testing (and use of the test suite) before commit. In fact it seems to me that Continuous Integration is only of use on projects where the full test suite cannot be run in the developer environment and so developers cannot integrate code changes into the code base without building/testing done by a dedicated environment (the continuous integration environment) and having this automated by connecting it to commits eliminates delay associated with needing someone with access to the continuous integration environment to push the "go test" button. Rails doesn't even have the concept of "build"ing code and so continuous integration becomes purely about testing, unless you also consider automated build of the whole rails application (including the webserver, database server, and reference data) to be part of continuous integration and then it is more useful but is it really applicable to a discussion of branching?

Martin Fowler (the link to Cont Int above is to an article by him) points out that code integration cost rises exponentially with time. His discussion on this is the best argument I've seen so far on working against the trunk, and as he points out, it isn't necessarily intuitive that frequently breaking things is positive (compared to infrequently trying to integrate things).

The biggest losses of working against the trunk in my eyes are:

* the clear separation of work by feature
* the ability to cherry pick functionality for testing and release
* no stable trunk available as a starting point
* branching encourages frequent commits because developers know they cannot impact others by committing

Whether or not to use feature branches depends on many factors including but not limited to team size, revision control repository brand, ease of communication between team members (are they even in the same country or time zone?), whether or not the developers are the same company as the owners of the repository and the project, the level of development activity, the type of changes being implemented, and the size of the code base.

I have a document that I'll add to over the next couple of weeks as aspects of version control come to mind. I think any discussion about trunking vs branching needs context and the answer will be different for different contexts.

I'm interested in looking at how branching/trunking choices are dependent on the technology employed. E.g. does Rails lend itself to a certain revision control style?

Essentially the overhead of feature branching needs to be small in comparison to the size of project undertaken. The overhead can be reduced through clear policies and perhaps automation.

Another factor in whether or not to use feature branching is the way in which a bug/issue tracker is used on a project. It can be very useful to mark on a ticket that a given branch contains the changes for the ticket.

A downside of feature branching can be that work needs to be done in addition to work in a branch that is not yet merged but this is essentially really about the bottleneck introduced by this method of quality control/code sign off.

I'll comment on the trunk vs branches later today if I find some free time... ;-)

We have a Subversion setup that might be of interest to you. It allows both authenticated and anonymous access in the same url space by using the AuthzSVNAccessFile directive.

With the following Apache configuration:

  
    DAV svn
    SVNParentPath /var/lib/svn
    SetOutputFilter DEFLATE
    SVNIndexXSLT "/stylesheets/svnindex.xsl"

    # use the access control file
    AuthzSVNAccessFile /var/lib/svn/access

    # try anonymous access first, use authentication if necessary
    Satisfy Any
    Require valid-user

    # define the authentication method
    AuthType Basic
    AuthName "Projects"
    AuthUserFile /var/lib/svn/passwd

You can have full access control for repositories and for specific paths within repositories. Some examples:

  # give thijs and manfred full access to all repositories
  [/]
  thijs = rw
  manfred = rw

  # allow public read access to the trunk of the smallsite repository
  [smallsite:/trunk]
  * = r

  # give annemarie full access to the bso repository
  [bso:/]
  annemarie = rw

For more information, see http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2

We're already using mod_authz_svn but thanks for the info. I think the more interesting point is your use of Satisfy Any. Will look at this later when I get a chance.

Update: I had to re-read the Satisfy documentation several times. I can see why I didn't try this before, I didn't understand that the discussion about IP restriction was blinding me to what was possible with a combination of mod_authz_svn and satisfy any. Got it working now, cheers Thijs.

You're right, it's the combination of the Satisfy Any directive and the access control file that allow Subversion to both do anonymous and authorized access.

Although I can see the benefits of working in separate branches for some kinds of projects and for really complex changes that touch a lot of different parts of the codebase, I think in most cases the cost of working with feature branches will be a lot higher than the cost of working against the trunk.

I'll go into what you think are the biggest losses of working against the trunk:

> the clear separation of work by feature

If you need to use your version control system for this, you're in trouble. ;-)

> the ability to cherry pick functionality for testing and release

Well, yeah, but the downside is that you have no idea of the different features you're picking are going to work together because they're all in different branches that have not yet been integrated.

> no stable trunk available as a starting point

I'm not really sure I understand what you mean with 'stable trunk' here, and for what it is supposed to be a starting point.

At Fingertips we always make sure that the test suite runs successfully before we commit to the trunk. That keeps the trunk 'stable' in the sense that all tests always run. If we're working on a project were we have 'stable' releases, we just tag that specific revision of the trunk.

> branching encourages frequent commits because developers know they cannot impact others by committing

IMHO the whole point is that developers know that their commit impacts other developers so that they take responsibility for only committing something sensible. I'm not interested in broken or incomplete code with incomprehensible commit messages.

Yes, it's good to have frequent commits, but it's a whole lot better to have per-feature of partial feature commits that work.