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