Re: [Libreoffice] Naming builds. Please???

On Tue, Dec 06, 2011 at 04:09:15AM -0800, Pedro wrote:

> <quote author="Lionel Elie Mamane">
> > 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
> </quote>

> I didn't understand this part. If at time 198 it is included in his
> personal repository wouldn't it make sense to use time 201 when the
> changes are known to all developers?

Prosaically, git does not keep track of time 201 (push time), so we
cannot know what that time actually is. And since git does not keep
track of it, it makes it harder to find a commit if one is given its
push time, while one can (with a modicum of work) search a commit by
commit time: It is shown in gitk and in "git log --format=fuller".

And actually it does not make a difference in terms of ambiguity in
practise, since no other changes recorded into another developer's
local repository between times 198 (commit time) and 201 (push time)
can be pushed successfully. I developer Jane has recorded another
change at time 200 in her personal repository, she necessarily does
not have Joe's change yet. When she tries to push her change at time
205, git will refuse, and Jane will have to fetch Joe's change (time
206), rebase her own change (time 207) and push it (time 208), so the
commit time for her change will be 207.

> Aren't the builds uploaded to the Tinderboxes supposed to be compiled
> from the Central repositories only?

Yes, they are. But if the system *also* works for a developer
distributing his own build to a tester, that's a nice extra.

> But I would still suggest using as epoch the TDF's Birth date
> (midnight Sept 28th 2010) and to use days as unit with the point
> separating days from the fraction part. It is easier to refer to a 3
> digit version as your email illustrates.

Yes, but an added advantage of using standard Unix timestamp is that
git can an also handle that format... As in:
 git --log --format=fuller --date=raw
Given a commit's commit time, one can then search in the output of
that for the exact timestamp.

Also consider:

 git log --since 1323142582 --until 1323156305

which gets all commits with author date between 1323142582 and
1323156305. Yes, *author* date, not *commit* date, that's the snag
right now, but if I get my way in the feature request I'm going to
make to git, the next version of git will have a "--commit-since" and
"--commit-until" for commit dates :)


Your format needs manual conversion to do that. But it has other
advantages, which you describe. So <shrug> I have no strong opinion on
this point.

-- 
Lionel