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
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
Hi Lionel, Petr, *
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.
While you (devs) think about this would it be possible to implement
the Pretty Print date on the About box to match the date
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
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 to
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
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 don't
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
Pedro Lino píše v So 03. 12. 2011 v 23:40 +:
Hi Lionel
Git commit IDs as identifiers have the huge problem that they are not
comparable (one cannot say which one is greater) without referring
to the repository. How about we also put the *commit* (not author)
timestamp (in UTC) of
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
Hi Pedro,
2011/12/3 Pedro Lino pedl...@gmail.com:
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
Hi Pedro
2011/12/3 Pedro Lino pedl...@gmail.com:
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
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 from.
On Sat, Dec 03, 2011 at 01:06:18PM +0100, Andras Timar wrote:
2011/12/3 Pedro Lino pedl...@gmail.com:
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
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 from.
Hi Korrawit
That is, if your 4f11d0a is the first group of IDs in About box, it's
the core repository's commit ID.
Yes, obviously. Sorry for the confusion.
I thought Andras was referring to the single 8 letter/number code
added to the Windows install folder name.
Where does that come from?
I thought Andras was referring to the single 8 letter/number code
added to the Windows install folder name.
Where does that come from?
No need to know. It is just a random (or not so random) sequence of
hex digits. If nothing documents it to have some significance, don't
assume it to have any
No need to know. It is just a random (or not so random) sequence of
hex digits. If nothing documents it to have some significance, don't
assume it to have any significance.
Thank you for the clarification. It does have some significance.
Anyway, even if this was a combination of the GIT IDs
On Sat, Dec 03, 2011 at 01:06:18PM +0100, Andras Timar wrote:
2011/12/3 Pedro Lino pedl...@gmail.com:
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
Hi Lionel
Git commit IDs as identifiers have the huge problem that they are not
comparable (one cannot say which one is greater) without referring
to the repository. How about we also put the *commit* (not author)
timestamp (in UTC) of the top node (commit), and maybe the branch?
That would
On Sat, Dec 03, 2011 at 11:40:01PM +, Pedro Lino wrote:
Git commit IDs as identifiers have the huge problem that they are not
comparable (one cannot say which one is greater) without referring
to the repository. How about we also put the *commit* (not author)
timestamp (in UTC) of the top
No, my idea was to put the above text in the about box, to replace our
current 4f11d0a-adcf6d5-... string.
Oh, I see! But then it would be easier to use the pretty printing
date instead of having 2 strings to compare for each repository. That
would be a nice improvement.
What I was proposing
22 matches
Mail list logo
