Is there a convenient way of mapping an update number to the commit
that produced that update number? I know that SqueakTrunk build #105 updated to update number 12360, but I don't know of a way of knowing "ah, that's Environments-fbs.11" (if indeed it was). frank |
No, I don't think we currently capture enough state to determine that.
On Thu, Jan 3, 2013 at 10:08 AM, Frank Shearar <[hidden email]> wrote: > Is there a convenient way of mapping an update number to the commit > that produced that update number? > > I know that SqueakTrunk build #105 updated to update number 12360, but > I don't know of a way of knowing "ah, that's Environments-fbs.11" (if > indeed it was). > > frank > |
So what would be needed to do that?
On 1/3/13, Chris Muller <[hidden email]> wrote: > No, I don't think we currently capture enough state to determine that. > > On Thu, Jan 3, 2013 at 10:08 AM, Frank Shearar <[hidden email]> > wrote: >> Is there a convenient way of mapping an update number to the commit >> that produced that update number? >> >> I know that SqueakTrunk build #105 updated to update number 12360, but >> I don't know of a way of knowing "ah, that's Environments-fbs.11" (if >> indeed it was). >> >> frank >> > > |
In reply to this post by Chris Muller-3
On 03.01.2013, at 19:49, Chris Muller <[hidden email]> wrote:
> No, I don't think we currently capture enough state to determine that. > > On Thu, Jan 3, 2013 at 10:08 AM, Frank Shearar <[hidden email]> wrote: >> Is there a convenient way of mapping an update number to the commit >> that produced that update number? >> >> I know that SqueakTrunk build #105 updated to update number 12360, but >> I don't know of a way of knowing "ah, that's Environments-fbs.11" (if >> indeed it was). >> >> frank It's not even a unique mapping anyway. What you could do is compare the package versions between one build and the next to see which packages changed. - Bert - |
On 7 January 2013 13:46, Bert Freudenberg <[hidden email]> wrote:
> On 03.01.2013, at 19:49, Chris Muller <[hidden email]> wrote: > >> No, I don't think we currently capture enough state to determine that. >> >> On Thu, Jan 3, 2013 at 10:08 AM, Frank Shearar <[hidden email]> wrote: >>> Is there a convenient way of mapping an update number to the commit >>> that produced that update number? >>> >>> I know that SqueakTrunk build #105 updated to update number 12360, but >>> I don't know of a way of knowing "ah, that's Environments-fbs.11" (if >>> indeed it was). >>> >>> frank > > It's not even a unique mapping anyway. What you could do is compare the package versions between one build and the next to see which packages changed. I'd argue that it _must_ be a unique mapping, from update number to a set of package versions. An update might point to multiple packages - 2121 -> {Foo-fbs.1 Bar-fbs.2}. Further, if any update N refers to a package version Foo-blah.M, then any update N+1, ... that refers to Foo should refer to a Foo-blah.K where K > M. But I take your point that - at least for now - a pragmatic approach to _determining_ the mapping (of the current update at least) is as you describe: take the set of mappings now, update one step, take the set of mappings again, and diff the two. frank > - Bert - > > |
On 07.01.2013, at 15:40, Frank Shearar <[hidden email]> wrote: > On 7 January 2013 13:46, Bert Freudenberg <[hidden email]> wrote: >> On 03.01.2013, at 19:49, Chris Muller <[hidden email]> wrote: >> >>> No, I don't think we currently capture enough state to determine that. >>> >>> On Thu, Jan 3, 2013 at 10:08 AM, Frank Shearar <[hidden email]> wrote: >>>> Is there a convenient way of mapping an update number to the commit >>>> that produced that update number? >>>> >>>> I know that SqueakTrunk build #105 updated to update number 12360, but >>>> I don't know of a way of knowing "ah, that's Environments-fbs.11" (if >>>> indeed it was). >>>> >>>> frank >> >> It's not even a unique mapping anyway. What you could do is compare the package versions between one build and the next to see which packages changed. > > I'd argue that it _must_ be a unique mapping, from update number to a > set of package versions. An update might point to multiple packages - > 2121 -> {Foo-fbs.1 Bar-fbs.2}. > > Further, if any update N refers to a package version Foo-blah.M, then > any update N+1, ... that refers to Foo should refer to a Foo-blah.K > where K > M. > > But I take your point that - at least for now - a pragmatic approach > to _determining_ the mapping (of the current update at least) is as > you describe: take the set of mappings now, update one step, take the > set of mappings again, and diff the two. > > frank For a single image, the mapping is indeed unique. But it is not necessarily the same for two given images. Close, usually, but not guaranteed, because it depends on the time you update. That's because packages are not loaded in the order they are committed, but in the order defined in the update config map. - Bert - |
Free forum by Nabble | Edit this page |