Improve SVN URL support (multiple address server environment)

[manu.blot@…]

In environment where the Trac (and usually SVN) server serves request on multiple address, multiple port or multiple protocol, the static coding of the SVN URL in the build recipes is an issue.

For example, the same Trac + Bitten installation can serve LAN requests with ​http://internal/project while it serves extranet requests on ​https://external:8080/project

It would be nice to have an automatic variable exposed to the build recipes that would provide the "server" part of the URL, that is protocol://host:port. For even more versatility, this variable could be split into its 3 main parts (protocol, host name, port number)

[manu.blot@…]

Automatic hostref variable for the experimental branch

[manu.blot@…]

Attached a quick proposal for the host reference variable.

It can be used in a build recipe as the following:

 <step id="checkout" description="Checkout source from repository">
    <svn:checkout url="${hostref}/svn/project"
        path="${path}" revision="${revision}" />
 </step>

[osimons]

Isn't Slave Configuration#Property Interpolationin Build Recipes a good working solution for this problem? Use a config file for slaves that substitutes the relevant prefix?

Any kind of generalisation on protocol://server:port or using req.href() is bound to not catch all use-cases, and especially when none of the code actually knows where or how repositories (or other services) are actually served? In my test setup for instance, I read the Subversion repository from disk (file:///) with the problem of my OSX and Windows clients needing different path specifications due to how shares are mapped.

Note to self: That Slave Configuration page should really be part of default documentation...

[osimons]

I've tested this some more, and consider using slave configurations with custom settings to really be the best general solution to this. Any objections to closing this ticket by adding good documentation about slave configuration to the default docs?

[eblot]

Replying to osimons:

I've tested this some more, and consider using slave configurations with custom settings to really be the best general solution to this. Any objections to closing this ticket by adding good documentation about slave configuration to the default docs?

Not tested, but seems ok to me.

[osimons]

See also #251 - different problem, same solution. I'll get the docs improved and into default set as this is a very useful feature.

[osimons]

New docs are added in [673] - see wiki:Documentation/configure.html