Which is better for configuring SVN VCS roots: parameters within URL or using checkout rules?

Which one is preferable and why, for configuring SVN VCS roots for multiple projects.

Given the following SVN repositories layout:

I see there are two possibilities:

Will the root be queried for changes once for the server or will there be multiple "requests" per period?
Also, performance wise which one is better?

Thank you.

Comment actions Permalink

Hi Stecy,

VCS roots with parameter are considered as different VCS roots. One VCS root checked out once and reused by build configurations. So the general recommendation is to have a small number of VCS roots (pointing to the root of the repository) and define what is checked out by a specific build configuration via checkout rules.
Please note that exclude checkout rules (in the form of "-:") will generally only speed up server-side checkouts. In case of agent-side checkout "exclude" VCS Checkout Rules cannot improve performance because an agent checks out the entire top-level directory included into a build, then deletes the files that were excluded.

Comment actions Permalink

So from my example, having one VCS root at for all the configurations will impact less the SVN server than having parameterized roots?

Also, why are the agents not smart enough to do the same processing as the server?

Comment actions Permalink

Yes, one VCS root will impact the SVN server less.

>Also, why are the agents not smart enough to do the same processing as the server?
In case of server side checkout the sources are cached and only the necessary changes are retrieved from the VCS server. In case of agent side checkout the sources are not cached and full repositoy is checked out the same way as performed by native SVN client. It does not make sense to cache sources, because each agent will have its own cache. Also the agent side checkout creates necessary administration directories (like

), and thus allows you to communicate with the repository from the build: commit changes and so on.

Please sign in to leave a comment.