RFR: JDK-8031567 Better model for storing source revision information

Erik Joelsson erik.joelsson at oracle.com
Fri Nov 25 15:56:42 UTC 2016


Looks good.

/Erik


On 2016-11-25 15:36, Magnus Ihse Bursie wrote:
> On 2016-11-24 16:13, Erik Joelsson wrote:
>> Hello,
>>
>> SourceRevision.gmk:34: typo "recreate"
>>
>> 70-74: Seems unnecessary to conditionally update the intermediate 
>> files since they are only read in the same makefile anyway. The 
>> conditional update does make sense for CreateSourceRevisionFile however.
>>
>> 88: indentation looks weird
>>
>> 113, 123, 127: Use LogWarn instead of echo?
>
> Updated webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.02
>
> /Magnus
>
>>
>> /Erik
>>
>>
>> On 2016-11-24 15:54, Magnus Ihse Bursie wrote:
>>> We are currently using "hg tip" to create the "source_tips" file, 
>>> and correspondingly for the closed bundles.
>>>
>>> But this is incorrect. It will show the latest committed version in 
>>> the repo, not the actual workspace (i.e. the version we actually 
>>> build).
>>>
>>> For this, we should use "hg id" instead. If we have a clean 
>>> workspace updated to the tip, it will produce the same output. 
>>> Otherwise it will show what we build, with a traliing "+" if there 
>>> are local, non-committed changed.
>>>
>>> Also, we should not name the file "tip" in this case.
>>>
>>> And finally, we do not need to sprinkle these files all around in 
>>> all repos. The entire handling should be more clearly abstracted.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031567
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01
>>>
>>> /Magnus
>>
>




More information about the build-dev mailing list