On Mon, Dec 05, 2011 at 06:37:09AM -0800, Pedro wrote:
Lionel Elie Mamane wrote
You may have missed that my "seconds since the epoch" (in my example:
1321480648) is also an age, and has mostly the same properties. It is
somewhat longer than your format, since it takes an earlier epoch (the
standard Unix epoch, 1 Jan 1970).
I don't care strongly which epoch we take; IMHO the Unix epoch is a bit
easier to handle since standard tools already know this format, but
that's a pretty minor point. <shrug>
I didn't miss it. But because I'm not a Dev, I'm not sure I understood.
Do you mean converting the time of extraction from the repositories to a
linear time?
No, I meant to use the time of the last change made to the
repository. This has the advantage that if two tinderboxes build the
same code at different times, the time will be the same. If someone
builds (for any reason) old code, the time shown will be old, too. And
it does not suffer from race conditions.
My proposition means that for a git sha1 commit id, we will always use
the same time.
For example:
Joe finds a but at time 152
Joe hacks, and fixes the bug at time 187
test, etc
at time 189, Joe commits fix to his local repository
at time 190, Joe tries to push the fix to the central repository at git.freedesktop.org
this fails, since there are new changes in the repo that Joe does not have yet
Joe downloads the new changes (git fetch) from time 192 to 196
Joe rebases (or merges) his changes with the new changes at time 198
Joe successfully pushes his changes to the central repository at time 201
Someone (tinderbox or Joe or another person) downloads the code - up
to the fix by Joe, but with no newer changes - at time 289, builds
from time 291 to 295.
In this example, I want to use time 198. Similarly, if someone sends a
patch to the list, we would use the time that the developer that
pushes the change has committed (or rebased/merged) that patch (to his
local commit.
In this example, your proposition is time 289, right? But then, if
another person downloads the very same code at time 315, the time in
the about box of his/her build will not be the same, while it is
exactly the same code. In my proposition, both builds will have time
198 in the about box.
If it's based on the last time they were updated wouldn't the value
be the same if all the repositories were updated at the same time?
Well, AFAIK the repositories are rarely updated (changed) at the same
time. The "help" or "artwork" repositories get far fewer commits than
the core (code) repository/.
--
Lionel
Context
- Re: [Libreoffice] [Libreoffice-qa] Naming builds. Please??? (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.