Having given up on externals (they’re too unreliable, and only seem to work at all on the trunk) I’ve tried to move some of our projects over to using multiple repositories plus repository rules and branch mapping. This works, but I really don’t want the users having the option of which branch to use for the various repositories… it should be entirely defined by the branch mappings as it’s somewhat nonintuitive if you’re not used to it.
At the moment if I select a release branch on our main project the dependent project stays at ‘Trunk’ - we’ve already had several cases where people have called me in saying the build is broke and they couldn’t work out why, which was traced to not selecting this option correctly.
Could an option be added to the repository to say ‘use branch mapping only’?
Hi Tony,
If you let us know more details about your issue with externals, we look into what we can do to make it work for you. They are working reliably for us and we have fixed a number of issues that other users had over time. Useful information would be the repository settings, details of the repository structure and locations of externals (e.g. output of “svn propget svn:externals -R”) and ideally a debug log covering the time the relevant revisions were added.
We like the idea of a “enable branch selection” option at the configuration level. Unticking this would turn off branch selection for all repositories in the queue options dialog. I’ve added this to our to-do list.
This will have the effect of always running builds for this configuration using branch mappings or defaults for all repositories, which should work for you unless you have a requirement to do this per configuration repository?
Meanwhile, if you don’t need to provide users with the ability to change variable values, you could disable to “queue build” button in the configuration wizard, only making the “quick start build” button available.
We’ve found externals to behave very inconstently. If the external is pointing at the trunk, it always works. If it’s pointing at another branch it’ll often fail to checkout (just not there in the workspace, as far as I could tell). A reset of the repository fixes it, and works for a short while then it breaks again. I was wondering if it was expecting the external branch name to match the main repository branch name, but never go the time to test (we had to find a solution so little time for testing).
I’ve not found a way to make externals tied to a specific revision to work, but that’s easily worked around by creating a branch (or tag).
Using multiple repositories and mappings works, but of course then there’s all the dropdowns…
For a specific example we had:
Main branch in /Branches/Application Release/
External in /Branches/Stable/
External would not check out reliably unless the repository was reset.
Main branch in /Trunk/
External in /Trunk/
Works more or less reliably
I had a look at the logs at the time but couldn’t see anything obvious.
I’d expect the setting not to switch off all branch selection, but only for those repositories that I have selected a mapping for… there will always be a ‘main’ repository that we want to select the branch for and a number of subordinate repositories that should be driven by mapping.
I appreciate that the configuration treats all repositories as equal now so it may not be easy to achieve.
Hi Tony,
OK, this sound like a useful feature. We could add an “Enforce branch mappings” option to the branch mapping dialog for a repository. I’d add this to our to-do list for investigation.
The externals issue looks like a bug which was reported and fixed last week. It happens when there is a space in the branch name (which gets URL encoded with a %20 in the external). This fix will be included in the next version out later today or tomorrow.