[Buildbot-devel] got_revision Build Property (w/ PATCH!)
warner-buildbot at lothar.com
Sat Mar 24 19:18:53 UTC 2007
Oz <oz at santacruzgames.com> writes:
> This function parses the output from "svnversion ." on a working copy.
> However, it assume that the stdout can always be converted to an int.
> svnversion can legally return all sorts of stuff. In addition to the plain
> revision number (for unmodified working copies), it can also return stuff
> like (this is from the --help):
> 4123:4168 mixed revision working copy
> 4168M modified working copy
> 4123S switched working copy
> 4123:4168MS mixed revision, modified, switched working copy
Ooh, that's a good one.
I'm not really sure what the best fix would be. The buildbot is generally
focussed on a VC model in which there is a checkout of a single specific
revision, and then maybe a patch is applied. So we can probably ignore the
'switched' part and the 4123:4168 mixed-revision part (by which I mean it is
ok if trees of this sort cause got_revision to be None, as long as a warning
message gets emitted somewhere).
The M suffix can happen either when the build process modifies some files (a
practice I would discourage, incidentally, but obviously there are times when
that is not worth the effort it would take to fix), and when you do a 'try'
build that applies a patch immediately after checkout. Since we already have
information on the buildmaster side as to whether or not a patch was applied,
we probably don't need to be aware of the M suffix, so it should be safe and
useful to just strip it.
Would it seem reasonable to apply a variant of your patch that only strips
the M and not the S, so that 'S' would cause a warning? And/or, maybe we
should provide a more obvious warning message if we see these sorts of trees.
FYI, the got_version=None default is there make sure that the build still
completes even if svn is in a weird state (maybe an older version of svn),
since I decided that the 'got_revision' build property is less important than
the checkout step itself. Was there a "unable to parse output of svnversion"
warning message in the logged output of the SVN step?
let me know and I'll apply the patch.
More information about the devel