Hi all,
On Tue, Dec 06, 2011 at 11:18:02PM +0100, Lionel Elie Mamane wrote:
> On Tue, Dec 06, 2011 at 04:09:15AM -0800, Pedro wrote:
> [very long thread]
I think the whole concept of manually tracking masterbuilds is mostly broken. I
think I have a better solution, and will post about it RSN. I w
Hi Lionel, Petr, *
> Your format needs manual conversion to do that. But it has other
> advantages, which you describe. So I have no strong opinion on
> this point.
While you (devs) think about this would it be possible to implement
the Pretty Print date on the About box to match the date includ
On Tue, Dec 06, 2011 at 04:09:15AM -0800, Pedro wrote:
>
>> 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
>
> I didn't understand
Hi Lionel, *
> 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
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 (
Hi Lionel
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
On Mon, Dec 05, 2011 at 02:30:07AM -0800, Pedro wrote:
> Stephan Bergmann-2 wrote
>> Using pretty-printed dates would make it easier to disambiguate the
>> seven-letter commit ID prefixes to the complete IDs (the commit
>> date would help narrow done in which commit range to look for the
>> given
Stephan Bergmann-2 wrote
>
> Using pretty-printed dates would make it easier to disambiguate the
> seven-letter commit ID prefixes to the complete IDs if later commits
> happen to introduce IDs with the same prefix (in which case the commit
> date would help narrow done in which commit range t
On 12/03/2011 10:16 PM, Lionel Elie Mamane wrote:
Something like:
Build assembled from:
repo commit date branch
core: 4f11d0a 2011-11-16 21:57:28 master
help: adcf6d5 2011-11-05 14:01:21 master
...
Or instead of pretty-printing the date, just put it as seconds
since the
On Sat, Dec 03, 2011 at 01:06:18PM +0100, Andras Timar wrote:
> 2011/12/3 Pedro Lino :
>> Another situation: I download a master build from a tinderbox. How do
>> I know the build included? How do I know if the source it was
>> generated from is newer or older than the one I already have? Easy.
>>
Hi again Andras
> We have 5 repositories now: core, binfilter, dictionaries, help, and
> translations. Therefore there are 5 git commit IDs in the About box
> separated by dashes. These are good identifiers of the build, at least
> these uniquely identify the source code that the build was made fr
Hi Pedro
2011/12/3 Pedro Lino :
> Hi Andras
>
> Thank you for your quick and enlightening reply!
>
>> LibreOffice 3.5 will not unpack anything to desktop. But we can't
>> change the past... :)
>
> Fair enough :)
>
>> You can check what's included and what's not, when you visit
>> for example
>> h
Hi Andras
Thank you for your quick and enlightening reply!
> LibreOffice 3.5 will not unpack anything to desktop. But we can't
> change the past... :)
Fair enough :)
> You can check what's included and what's not, when you visit
> for example
> http://cgit.freedesktop.org/libreoffice/core/log/
Hi Pedro,
2011/12/3 Pedro Lino :
> Hi all
>
> This is my final request about this subject.
>
> Can you please make some sense out of the version naming convention?
>
> I was about to reinstall version 3.4.4 (after it was overwritten by
> 3.5.0 Beta0) and I already had an unpacked install folder on
Hi all
This is my final request about this subject.
Can you please make some sense out of the version naming convention?
I was about to reinstall version 3.4.4 (after it was overwritten by
3.5.0 Beta0) and I already had an unpacked install folder on my
desktop. The only way I could verify that i
15 matches
Mail list logo
