Checkout finds which branch or tag to work on.

[mpotter@…]

Add to the svn:checkout command (or to the recipes) the ability for it to figure out which branch or tag to check out.

Example: I am currently doing this via a batch file (sorry Windows). I have a set of recipes which:

• Are aimed at svn:/path/tags
• The first step in the recipe has a batch file which:
  • Takes as a parameter the revision number and the base SVN path.
  • Using svn it figures out what svn path has that revision number
    • svn list -v %SVNPATH%@%REV% then look for the line which contains %REV%
    • Extract the name and then checkout %SVNPATH%/%NAME%@%REV%

Thus if anyone makes a new tag, it will be checked out, built, unit-tested, and the resulting executables made available for QA, and eventual release.

Issues and pit-falls:

• The shared_path feature of checkout may be incompatible with this new feature, unless augmented.
• The Build all revisions global configuration may need to be relaxed.
  • e.g. If someone makes a tag of /path/tags/V31_RC2 and then someone makes another of /path/tags/V40_RC1, if Build all revisions is disabled then the first tag would not be built.
  • This is a weakness with my current implementation, but tags are so rare it hasn't been an issue.

[mpotter@…]

Replying to mpotter@…:

Add to the svn:checkout command (or to the recipes) the ability for it to figure out which branch or tag to check out.

By "or to the recipes", I was referring to the Path setting in a recipe configuration. Some additional flag could be added to the recipe configuration near the Path setting which is used to enable this new feature. If enabled, when the slave requests a recipe, the server will have already figured out the sub-path off of the configured path to give to the slave.

[mpotter@…]

The approach of being a feature of the recipe as opposed to the svn:checkout has the advantage of:

If there is a check-in that does not affect one and only one sub-path, the svn:checkout method would fail or would do the wrong thing.

• e.g. A deletion of a branch or tag. (affect no sub-path)
  • The svn:checkout method would see no possible paths to check-out and thus would have to fail, thus failing the build.
  • The recipe approach would see no possible paths, and thus would add no entry to the build queue.
• e.g. A check-in of an attribute change which affects the entire repository (or all of the tags or all of the branches). (affects more that one sub-path)
  • The svn:checkout method would see multiple possible paths to check out, it would then have to either fail or build one of the many it should.
  • The recipe approach would also see the multiple possible paths, but it could either add no entires to the build queue or add all the possible entries to the build queue.
    • I am not sure which is the correct approach, but I would assume that it is to make no queue entries.