harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: Numbering of snapshots/release candidates/etc
Date Wed, 03 Oct 2007 10:47:36 GMT
Stepan Mishura wrote:
> On 10/3/07, Mark Hindess wrote:
>> On 3 October 2007 at 13:34, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>> Mark Hindess wrote:
>>>> On 3 October 2007 at 13:32, "Stepan Mishura" <stepan.mishura@gmail.com>
>>> te:
>>>>> On 10/2/07, Mark Hindess <mark.hindess@googlemail.com> wrote:
>>>>>> Something to think about after M3...
>>>>>> On 2 October 2007 at 14:46, "Stepan Mishura" <stepan.mishura@gmail.com>
>>> 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.

I don't quite understand what is the difference between current revision 
number that is >= "Last Changed Rev", but denotes a revision that has no 
changes since "Last Changed Rev" in Harmony source tree.

As far as I understand checking out harmony with currently used revision 
numbers and "Last Changed Rev" should produce identical source trees for 
Harmony, so it is just a matter of naming snapshots. If a snapshot is 
broken for the "Last Changed Rev" it shall remain broken until some 
changes are done to the source code which will change "Last Changed Rev" 


View raw message