|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Potential Use Case #2:
Suppose a site has a single SVN repository for all of their code modules and this repository is shared across many teams and projects. In such a case there are typically commits occurring frequently enough that CI builds - even those triggered my non SCM changes - are likely to get a new "latest revision" every time they do an SVN update.
In such a case it is feasible to use the SVN revision number as a universal unique identifier for any particular build of any particular module. For convenience it is handy to propagate this revision number throughout the system, using it as the unique identifier for all CI artifacts (builds, tests, releases, packages, etc.)
Now, in order for such a configuration to rely on the SVN revision number being unique (at least in most cases) they need to leverage the "latest" revision number of a working folder rather than the "last changed" revision - particularly for those cases when a build is manually triggered (manual triggers would do an SVN update even if there were no changes to that particular module, and the resulting "latest revision" would be updated accordingly).
In such a configuration using the last change revision can not always ensure uniqueness in the build number, however so long as the frequency of modifications to the central repository is high enough (which in a large system it typically is) the "latest" revision can effectively be used.