On 10/3/07, Mark Hindess wrote: > > On 3 October 2007 at 13:34, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > > On 3 October 2007 at 13:32, "Stepan Mishura" <[EMAIL PROTECTED]> wro > > te: > > >> On 10/2/07, Mark Hindess <[EMAIL PROTECTED]> wrote: > > >>> Something to think about after M3... > > >>> > > >>> On 2 October 2007 at 14:46, "Stepan Mishura" <[EMAIL PROTECTED]> w > > ro > > >> te: > > >>>> Hi, > > >>>> > > >>>> Currently, the next milestone candidate (r580985) is under testing. > > >>> It might be more consistent if we named candidates/snapshots/etc > > >>> using the canonical revision number - i.e. the last change revision > > >>> number - rather than some arbitrary revision number after it (and > > >>> before the next change). > > >>> > > >> I agree. I think this may correlate with auto selection of revision > > >> number for the next snapshot. The idea is to create automation for > > >> collecting/analysing integrity testing results and choosing the best > > >> revision for some period of time (for example, 48 hours) > > > > > > Sounds good so long as we can find a way to pick the best revision > > > without doing too many queries against the svn server. ;-) > > > > I think it is possible to use "svn info" to get "Last Changed Rev" out > > of the repository. It doesn't query the server at all. > > Of course, and that is what I had in mind when suggesting we fix our > processes, but it sounded like Stepan had something more sophisticated > in mind.
There is a chance that the code for the "Last Changed Rev" is broken and it doesn't make sense to build and test a new snapshot. We publish 3 snapshots per week and there were cases when we had only 1 snapshot because of broken build, mass tests failures ... I think we should avoid publishing broken snapshots. Thanks, Stepan.
