No 7.3a patchlevels?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

No 7.3a patchlevels?

Tony Mechelynck
Hello, I notice that no "patch numbers" are added to the 7.3a version.c.
That's OK for me except that it may make it harder in the future to
track exactly on which build some bug was seen. Mercurial relative
revisions are not a reliable reference: for instance on my local
repository there's one additional revision every time I "fetch" the
source (if there is a change in one or more of src/version.c,
src/Makefile, src/eval.c or src/feature.h): for instance my current
vim73 "head" is at local revision count 2193. I don't know if Mercurial
hashes are carried over (the short hash for Bram's vim73 parent to my
latest merge is listed as c6f1aa1e9f32 with the description "Add
'relativenumber' patch from Markus Heidelberg") and anyway they aren't
taken over in the resulting executable.

Best regards,
Tony.
--
There's only one way to have a happy marriage and as soon as I learn
what it is I'll get married again.
                -- Clint Eastwood

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

scott-268
On Sunday 16 May 2010 11:09:15 am Tony Mechelynck wrote:

> hashes are carried over (the short hash for Bram's vim73
>  parent to my  latest merge is listed as c6f1aa1e9f32 with the
>  description "Add 'relativenumber' patch from Markus
>  Heidelberg") and anyway they aren't taken over in the
>  resulting executable.

they were for me

the difference i think is in the way you updated

my update script does

    hg pull -u
    hg update

mercurial then told me a merge might be a good idea, so i did one

the merge reminded me to commit, so i then did that

relative numbers are now, for me, a mainstream reality

dunno why you like that 'fetch' better, but for me the
pull/update work famously

sc

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 16/05/10 18:51, sc wrote:

> On Sunday 16 May 2010 11:09:15 am Tony Mechelynck wrote:
>
>> hashes are carried over (the short hash for Bram's vim73
>>   parent to my  latest merge is listed as c6f1aa1e9f32 with the
>>   description "Add 'relativenumber' patch from Markus
>>   Heidelberg") and anyway they aren't taken over in the
>>   resulting executable.
>
> they were for me
>
> the difference i think is in the way you updated
>
> my update script does
>
>      hg pull -u
>      hg update
>
> mercurial then told me a merge might be a good idea, so i did one
>
> the merge reminded me to commit, so i then did that
>
> relative numbers are now, for me, a mainstream reality
>
> dunno why you like that 'fetch' better, but for me the
> pull/update work famously
>
> sc
>

When I do a pull -u, it tells me no update could be done because a merge
is necessary.

When I do a merge it tells me to do a commit.

Then I have to do a commit and not forget the commit message, else Vim
comes up as Mercurial's custom editor, asking for one.

Total 3 operations, or 4 if I forget the -m 'something sensible'

hg fetch (with the fetch extension enabled) does the pull-merge-commit
(or pull-update if no merge is needed, or nothing at all, except tell
me, if no pull is needed) in one step, and adds a reasonable commit
message. Much less hassle.

FWIW it merged eval.c (which I have patched with Bill McCarthy's "Extra
float functions") but not version.c, and the latter still includes

static int included_patches[] =
{   /* Add new patch number below this line */
/**/
     0
};

at lines 682-686, i.e. "patchlevel zero". OTOH the 'relativenumber'
option is supported: when I ask

        :set relat<Tab>

Vim completes with

        :set relativenumber|

where | is the cursor; so I add a question mark and hit Enter:

        :set relativenumber?
norelativenumber

meaning it is supported but currently not set. My post was not about
Vim's 'relativenumber' option not being supported but about no "Included
patches" in the :version output. Do you have that "Included patches"
line? I don't, so the next time I report a 7.3a bug it won't be easy for
me to say precisely which patches were or weren't included compared to
the _first_ 7.3a set of sources issued by Bram. And, as I said, saying
that I am "at relative changeset #2193" won't mean a thing, because
every commit that I do (e.g. after a merge, including those done
implicitly by fetch) adds an ordinal number not present in Bram's repo.
Every merge that you commit also adds one, but I bet we don't do them
exactly as frequently, so one of us will have more changesets than the
other in his local repo, even if we have the exact same set of official
patches included.

When I said Mercurial hashes aren't taken over in the executable, I
meant there is nothing in my running Vim which will tell me «This Vim
version includes changeset c6f1aa1e9f32 about "Add 'relativenumber'
patch from Markus Heidelberg"». The _hash_ c6f1aa1e9f32 is what is not
taken up. The changeset (i.e., the corresponding set of changes to the C
sources) is. And the half-sentence which you cut at the top of this post
said that I don't know whether what is called "changeset c6f1aa1e9f32"
in my repository is or isn't known to Mercurial by the same string of
hex digits in Bram's repo, or in yours.


Best regards,
Tony.
--
"The way to make a small fortune in the commodities market is to start
with a large fortune."

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

James Vega-3
In reply to this post by Tony Mechelynck
On Sun, May 16, 2010 at 06:09:15PM +0200, Tony Mechelynck wrote:
> I
> don't know if Mercurial hashes are carried over (the short hash for
> Bram's vim73 parent to my latest merge is listed as c6f1aa1e9f32
> with the description "Add 'relativenumber' patch from Markus
> Heidelberg") and anyway they aren't taken over in the resulting
> executable.

The hashes are global to all clones of a given repository.  That is, any
commit which is shared among clones will have the same hash.  That's how
Mercurial knows which changesets have been applied.  The changeset index
is local to each clone simply as a convenience so you don't have to type
out full hashes.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 16/05/10 21:26, James Vega wrote:

> On Sun, May 16, 2010 at 06:09:15PM +0200, Tony Mechelynck wrote:
>> I
>> don't know if Mercurial hashes are carried over (the short hash for
>> Bram's vim73 parent to my latest merge is listed as c6f1aa1e9f32
>> with the description "Add 'relativenumber' patch from Markus
>> Heidelberg") and anyway they aren't taken over in the resulting
>> executable.
>
> The hashes are global to all clones of a given repository.  That is, any
> commit which is shared among clones will have the same hash.  That's how
> Mercurial knows which changesets have been applied.  The changeset index
> is local to each clone simply as a convenience so you don't have to type
> out full hashes.
>

Ah, I see. I wonder how Mercurial makes sure that a changeset I import
will never have a hash (not even a 12-nybble "short hash") already used
by an earlier "local commit". Saying that "it will never happen" because
the apriori probability is thought to be low strikes me as the wrong way
to set up server software (see Murphy's law). Oh, well, I'll worry about
it when I see it happen.


Best regards,
Tony.
--
Ask not for whom the telephone bell tolls ... if thou art in the
bathtub, it tolls for thee.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

scott-268
In reply to this post by Tony Mechelynck
On Sunday 16 May 2010 2:19:53 pm Tony Mechelynck wrote:

> meaning it is supported but currently not set. My post was not
>  about  Vim's 'relativenumber' option not being supported but
>  about no "Included patches" in the :version output. Do you
>  have that "Included patches" line? I don't, so the next time
>  I report a 7.3a bug it won't be easy for me to say precisely
>  which patches were or weren't included compared to the first
>  7.3a set of sources issued by Bram. And, as I said, saying
>  that I am "at relative changeset #2193" won't mean a thing,
>  because every commit that I do (e.g. after a merge, including
>  those done implicitly by fetch) adds an ordinal number not
>  present in Bram's repo. Every merge that you commit also adds
>  one, but I bet we don't do them exactly as frequently, so one
>  of us will have more changesets than the other in his local
>  repo, even if we have the exact same set of official patches
>  included.

forgive me, please, for misunderstanding you, and probably also
for snipping in mid-sentence

my question now is, what would you have bram do?  7.3 is beta --
he is patching 7.2 -- would you like him to create two sets of
patches, each with different names but with the same content?

7.2.434    ==    7.3.001
7.2.435    ==    7.3.002
7.2.436    ==    7.3.003

i believe he does quite enough as it is, and i do not go looking
for ways to make it more complicated for him

sc

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 16/05/10 22:30, sc wrote:

> On Sunday 16 May 2010 2:19:53 pm Tony Mechelynck wrote:
>
>> meaning it is supported but currently not set. My post was not
>>   about  Vim's 'relativenumber' option not being supported but
>>   about no "Included patches" in the :version output. Do you
>>   have that "Included patches" line? I don't, so the next time
>>   I report a 7.3a bug it won't be easy for me to say precisely
>>   which patches were or weren't included compared to the first
>>   7.3a set of sources issued by Bram. And, as I said, saying
>>   that I am "at relative changeset #2193" won't mean a thing,
>>   because every commit that I do (e.g. after a merge, including
>>   those done implicitly by fetch) adds an ordinal number not
>>   present in Bram's repo. Every merge that you commit also adds
>>   one, but I bet we don't do them exactly as frequently, so one
>>   of us will have more changesets than the other in his local
>>   repo, even if we have the exact same set of official patches
>>   included.
>
> forgive me, please, for misunderstanding you, and probably also
> for snipping in mid-sentence
>
> my question now is, what would you have bram do?  7.3 is beta --
> he is patching 7.2 -- would you like him to create two sets of
> patches, each with different names but with the same content?
>
> 7.2.434    ==    7.3.001
> 7.2.435    ==    7.3.002
> 7.2.436    ==    7.3.003
>
> i believe he does quite enough as it is, and i do not go looking
> for ways to make it more complicated for him
>
> sc
>

Bram will do what he will do. Since 7.3 (final) isn't released yet, he
might (if he thinks it worth while) make patches labeled 7.3a.001,
7.3a.002, etc., which may or may not reflect 7.2 patches above 433. (I
imagine it is quite possible that some 7.3a patches won't be ported back
to 7.2.) I think (but maybe he thinks otherwise) that if he does it will
be easier for everyone including him when someone finds a bug, so that
one may say e.g. "I get this crash in gvim 7.3a.008 with GTK2 GUI" and
everyone will understand, and maybe some other regular will pass by and
say "Oh, but that was fixed in 7.3a.012". Or else, if someone proposes a
patch, "This patch is against 7.3a.007 sources" and again the meaning
will be obvious, even though with context diffs (well, unified diffs
now, since hg diff never produces "classical" context diffs) patch can
usually figure how many lines up or down to apply the patch, and with
the "diff -r af32cb245cca src/misc.c" (or similar) line at the top,
Mercurial might know how to merge even though it's not very
"human-readable".


Best regards,
Tony.
--
RULES OF EATING -- THE BRONX DIETER'S CREED
        (1)  Never eat on an empty stomach.
        (2)  Never leave the table hungry.
        (3)  When traveling, never leave a country hungry.
        (4)  Enjoy your food.
        (5)  Enjoy your companion's food.
        (6)  Really taste your food.  It may take several portions to
             accomplish this, especially if subtly seasoned.
        (7)  Really feel your food.  Texture is important.  Compare,
             for example, the texture of a turnip to that of a
             brownie.  Which feels better against your cheeks?
        (8)  Never eat between snacks, unless it's a meal.
        (9)  Don't feel you must finish everything on your plate.  You
             can always eat it later.
        (10) Avoid any wine with a childproof cap.
        (11) Avoid blue food.
                -- Richard Smit, "The Bronx Diet"

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Bram Moolenaar
In reply to this post by Tony Mechelynck

Tony Mechelynck wrote:

> Hello, I notice that no "patch numbers" are added to the 7.3a version.c.
> That's OK for me except that it may make it harder in the future to
> track exactly on which build some bug was seen. Mercurial relative
> revisions are not a reliable reference: for instance on my local
> repository there's one additional revision every time I "fetch" the
> source (if there is a change in one or more of src/version.c,
> src/Makefile, src/eval.c or src/feature.h): for instance my current
> vim73 "head" is at local revision count 2193. I don't know if Mercurial
> hashes are carried over (the short hash for Bram's vim73 parent to my
> latest merge is listed as c6f1aa1e9f32 with the description "Add
> 'relativenumber' patch from Markus Heidelberg") and anyway they aren't
> taken over in the resulting executable.

There are no patch levels, this is work in progress.

Once public beta testing starts I'll use patches as usual.

--
hundred-and-one symptoms of being an internet addict:
50. The last girl you picked up was only a jpeg.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Benjamin R. Haskell-8
In reply to this post by Tony Mechelynck
On Sun, 16 May 2010, Tony Mechelynck wrote:

> On 16/05/10 21:26, James Vega wrote:
> > On Sun, May 16, 2010 at 06:09:15PM +0200, Tony Mechelynck wrote:
> > > I don't know if Mercurial hashes are carried over (the short hash
> > > for Bram's vim73 parent to my latest merge is listed as
> > > c6f1aa1e9f32 with the description "Add 'relativenumber' patch from
> > > Markus Heidelberg") and anyway they aren't taken over in the
> > > resulting executable.
> >
> > The hashes are global to all clones of a given repository.  That is,
> > any commit which is shared among clones will have the same hash.  
> > That's how Mercurial knows which changesets have been applied.  The
> > changeset index is local to each clone simply as a convenience so
> > you don't have to type out full hashes.
> >
>
> Ah, I see. I wonder how Mercurial makes sure that a changeset I import
> will never have a hash (not even a 12-nybble "short hash") already
> used by an earlier "local commit".

It doesn't (and can't) mathematically guarantee no collisions in the
full hash.  The input space is far larger [text of any length] than the
output space [non-negative integers from 0 to 2^160-1].

> Saying that "it will never happen" because the apriori probability is
> thought to be low strikes me as the wrong way to set up server
> software (see Murphy's law). Oh, well, I'll worry about it when I see
> it happen.

It's not just that "the apriori probability is thought to be low", it's
that it's thought to be astronomically low.

There's a Mercurial FAQ[1] that sums it up well:

"""
7.11. What about hash collisions? What about weaknesses in SHA1?

The SHA1 hashes are large enough that the odds of accidental hash
collision are negligible for projects that could be handled by the human
race. The known weaknesses in SHA1 are currently still not practical to
attack, and Mercurial will switch to SHA256 hashing before that becomes
a realistic concern.

Collisions with the "short hashes" are not a concern as they're always
checked for ambiguity and are still long enough that they're not likely
to happen for reasonably-sized projects (< 1M changes).
"""

The "short hash" isn't used in "mission-critical" contexts.  (As with
the local 'revision numbers', it's merely for convenience.)

As with the crypto-law conversation, probably getting a bit offtopic for
vim-dev, but if you're interested, some more reading in the links
below[2][3].

--
Best,
Ben

[1] http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.What_about_hash_collisions.3F_What_about_weaknesses_in_SHA1.3F

[2] Why SHA-1 shouldn't be of concern (in the context of Perl's git repo)
http://use.perl.org/~schwern/journal/37600

[3] Re: SHA1 hash safety (again git, but the same applies to hg)
http://www.gelato.unsw.edu.au/archives/git/0504/0724.html

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 17/05/10 00:02, Benjamin R. Haskell wrote:

> On Sun, 16 May 2010, Tony Mechelynck wrote:
>
>> On 16/05/10 21:26, James Vega wrote:
>>> On Sun, May 16, 2010 at 06:09:15PM +0200, Tony Mechelynck wrote:
>>>> I don't know if Mercurial hashes are carried over (the short hash
>>>> for Bram's vim73 parent to my latest merge is listed as
>>>> c6f1aa1e9f32 with the description "Add 'relativenumber' patch from
>>>> Markus Heidelberg") and anyway they aren't taken over in the
>>>> resulting executable.
>>>
>>> The hashes are global to all clones of a given repository.  That is,
>>> any commit which is shared among clones will have the same hash.
>>> That's how Mercurial knows which changesets have been applied.  The
>>> changeset index is local to each clone simply as a convenience so
>>> you don't have to type out full hashes.
>>>
>>
>> Ah, I see. I wonder how Mercurial makes sure that a changeset I import
>> will never have a hash (not even a 12-nybble "short hash") already
>> used by an earlier "local commit".
>
> It doesn't (and can't) mathematically guarantee no collisions in the
> full hash.  The input space is far larger [text of any length] than the
> output space [non-negative integers from 0 to 2^160-1].
>
>> Saying that "it will never happen" because the apriori probability is
>> thought to be low strikes me as the wrong way to set up server
>> software (see Murphy's law). Oh, well, I'll worry about it when I see
>> it happen.
>
> It's not just that "the apriori probability is thought to be low", it's
> that it's thought to be astronomically low.
>
> There's a Mercurial FAQ[1] that sums it up well:
>
> """
> 7.11. What about hash collisions? What about weaknesses in SHA1?
>
> The SHA1 hashes are large enough that the odds of accidental hash
> collision are negligible for projects that could be handled by the human
> race. The known weaknesses in SHA1 are currently still not practical to
> attack, and Mercurial will switch to SHA256 hashing before that becomes
> a realistic concern.
>
> Collisions with the "short hashes" are not a concern as they're always
> checked for ambiguity and are still long enough that they're not likely
> to happen for reasonably-sized projects (<  1M changes).
> """
>
> The "short hash" isn't used in "mission-critical" contexts.  (As with
> the local 'revision numbers', it's merely for convenience.)
>
> As with the crypto-law conversation, probably getting a bit offtopic for
> vim-dev, but if you're interested, some more reading in the links
> below[2][3].
>

Ah, thanks, I'll make sure to keep this post where I can easily get back
to it. :-)


Best regards,
Tony.
--
WOMAN:   Dennis, there's some lovely filth down here.  Oh -- how d'you do?
ARTHUR:  How do you do, good lady.  I am Arthur, King of the Britons.
          Whose castle is that?
WOMAN:   King of the who?
                                   The Quest for the Holy Grail (Monty
Python)

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
In reply to this post by Bram Moolenaar
On 16/05/10 23:08, Bram Moolenaar wrote:
[...]
> There are no patch levels, this is work in progress.
>
> Once public beta testing starts I'll use patches as usual.
>

Ah, well, for "not yet public beta" these builds work already remarkably
well (like I already noticed some time ago about the 7.00aa "snapshots") :-)

Best regards,
Tony.
--
Hofstadter's Law:
        It always takes longer than you expect, even when you take
Hofstadter's Law into account.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Markus Heidelberg
In reply to this post by Tony Mechelynck
Tony Mechelynck, 2010-05-16 18:09:
> for instance on my local
> repository there's one additional revision every time I "fetch" the
> source (if there is a change in one or more of src/version.c,
> src/Makefile, src/eval.c or src/feature.h)

A few days ago I told you that it has *nothing* to do with your 4
locally modified files. Thanks for listening. I stop trying to help now,
you will find it out yourself.

But in short: the "Automated merge" changeset will always be created
because, even if there are no changes in your 4 modified files and thus
Mercurial doesn't has to merge on file level, it still has to merge on
history level.

Markus

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 18/05/10 22:07, Markus Heidelberg wrote:

> Tony Mechelynck, 2010-05-16 18:09:
>> for instance on my local
>> repository there's one additional revision every time I "fetch" the
>> source (if there is a change in one or more of src/version.c,
>> src/Makefile, src/eval.c or src/feature.h)
>
> A few days ago I told you that it has *nothing* to do with your 4
> locally modified files. Thanks for listening. I stop trying to help now,
> you will find it out yourself.
>
> But in short: the "Automated merge" changeset will always be created
> because, even if there are no changes in your 4 modified files and thus
> Mercurial doesn't has to merge on file level, it still has to merge on
> history level.
>
> Markus
>

Don't get up in a rage, Markus, I'm still learning this stuff. I've
never used a version-control system before and I'm making mistakes as I
go along. Okay, the parenthesis was unnecessary; but the point I was
making in that post (or maybe in that other post) was that I don't have
the same number of revisions as Bram (because of the additional merges
however many) or even as some other guy even if he too has local changes
(because one of us may pull several of Bram's revisions together,
resulting in just one merge, while the other may pull them in two or
more runs, resulting in that many merges). IIUC the point is still valid
but not really important, it just means the revision count (the ordinal
revision number) has no meaning when comparing different clones of one
repository -- what is comparable is Bram's latest revision (one of the
parents of the "tip" merge, in a repo with local changes) at the time of
the compile. The problem with that is that though it is possible to say
"this is the same revision as that", it is not obvious, when different,
to say which is the latest one. For that we would need a time reference
or something.


Best regards,
Tony.
--
        So Richard and I decided to try to catch [the small shark].
With a great deal of strategy and effort and shouting, we managed to
maneuver the shark, over the course of about a half-hour, to a sort of
corner of the lagoon, so that it had no way to escape other than to
flop up onto the land and evolve.  Richard and I were inching toward
it, sort of crouched over, when all of a sudden it turned around and --
I can still remember the sensation I felt at that moment, primarily in
the armpit area -- headed right straight toward us.
        Many people would have panicked at this point.  But Richard and
I were not "many people."  We were experienced waders, and we kept our
heads.  We did exactly what the textbook says you should do when you're
unarmed and a shark that is nearly two feet long turns on you in water
up to your lower calves: We sprinted I would say 600 yards in the
opposite direction, using a sprinting style such that the bottoms of
our feet never once went below the surface of the water.  We ran all
the way to the far shore, and if we had been in a Warner Brothers
cartoon we would have run right INTO the beach, and you would have seen
these two mounds of sand racing across the island until they bonked
into trees and coconuts fell onto their heads.
                -- Dave Barry, "The Wonders of Sharks on TV"

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 19/05/10 12:34, Tony Mechelynck wrote:
> [...] what is comparable is Bram's latest revision

...ID (in hex, 12 or 40 nybbles)...

> (one of the
> parents of the "tip" merge, in a repo with local changes) at the time of
> the compile. The problem with that is that though it is possible to say
> "this is the same revision as that", it is not obvious, when different,
> to say which is the latest one. For that we would need a time reference
> or something.
>
>
> Best regards,
> Tony.
--
        The men sat sipping their tea in silence.  After a while the
klutz said, "Life is like a bowl of sour cream."

        "Like a bowl of sour cream?" asked the other.  "Why?"

        "How should I know?  What am I, a philosopher?"

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Xavier de Gaye-2
In reply to this post by Tony Mechelynck
On Wed, May 19, 2010 at 12:34 PM, Tony Mechelynck wrote:
> ...
> .... The problem with that is that though it
> is possible to say "this is the same revision as that", it is not obvious,
> when different, to say which is the latest one. For that we would need a
> time reference or something.
> ...


This may be handled with a mercurial hook that creates a source file
(after each commit or update command) defining a variable whose value
is the hash of the last changeset. With this source file built into
vim, the hash value could then be printed with the ':version' command,
for example.

This is better explained in
http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html


Xavier

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 19/05/10 14:29, Xavier de Gaye wrote:

> On Wed, May 19, 2010 at 12:34 PM, Tony Mechelynck wrote:
>> ...
>> .... The problem with that is that though it
>> is possible to say "this is the same revision as that", it is not obvious,
>> when different, to say which is the latest one. For that we would need a
>> time reference or something.
>> ...
>
>
> This may be handled with a mercurial hook that creates a source file
> (after each commit or update command) defining a variable whose value
> is the hash of the last changeset. With this source file built into
> vim, the hash value could then be printed with the ':version' command,
> for example.
>
> This is better explained in
> http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html
>
>
> Xavier
>

Well, that is interesting; the idea sounds like the Mercurial changeset
which recent versions of Mozilla applications (Firefox, Thunderbird,
SeaMonkey, ...) display near the top of the about:buildconfig page, e.g.
the part after the last slash in


Source

Built from http://hg.mozilla.org/mozilla-central/rev/0459345d8026


(For Thunderbird you need to set about:buildconfig as a "Mail Start
Page" to see it.)

But even if I patched version.c to add one more line to the output of
":version", for me the latest changeset would always be my latest commit
(usually a merge, unless I recently made some new local changes), and
that would not be relevant to you all. I can do with typing "hg tip"
(or, after local changes, "hg log -l <number> -f" with a well-chosen
<number>) to get (by copy-paste from xterm etc.) the latest changeset
made by Bram, which would be the one just before my latest merge.


Best regards,
Tony.
--
Usage: fortune -P [] -a [xsz] [Q: [file]] [rKe9] -v6[+] dataspec ...
inputdir

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Xavier de Gaye-2
On Wed, May 19, 2010 at 3:36 PM, Tony Mechelynck wrote:
>
> But even if I patched version.c to add one more line to the output of
> ":version", for me the latest changeset would always be my latest commit
> (usually a merge, unless I recently made some new local changes), and that
> would not be relevant to you all. I can do with typing "hg tip" (or, after
> local changes, "hg log -l <number> -f" with a well-chosen <number>) to get
> (by copy-paste from xterm etc.) the latest changeset made by Bram, which
> would be the one just before my latest merge.
>


Hi Tony,

The following command lists the local changesets not
found in Bram's repository:

    $ hg outgoing


I am managing some vim patches for pyclewn with the mq extension
(Mercurial queues). The following simple command outputs the latest
changeset made by Bram on which my patches are applied:

    $ hg parents -r qbase
    changeset:   2172:e12b9d992389
    tag:         qparent
    parent:      2170:cf8f86128f4c
    user:        Bram Moolenaar <[hidden email]>
    date:        Sun May 16 13:56:06 2010 +0200
    summary:     updated for version 7.2.436

Another advantage of using mq when applying patches, is that the patch
changeset id is temporary: when you apply the patch to a more recent
Bram's repository version, a new changeset id is created and the old
one is forgotten.


Xavier

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: No 7.3a patchlevels?

Tony Mechelynck
On 19/05/10 18:53, Xavier de Gaye wrote:

> On Wed, May 19, 2010 at 3:36 PM, Tony Mechelynck wrote:
>>
>> But even if I patched version.c to add one more line to the output of
>> ":version", for me the latest changeset would always be my latest commit
>> (usually a merge, unless I recently made some new local changes), and that
>> would not be relevant to you all. I can do with typing "hg tip" (or, after
>> local changes, "hg log -l<number>  -f" with a well-chosen<number>) to get
>> (by copy-paste from xterm etc.) the latest changeset made by Bram, which
>> would be the one just before my latest merge.
>>
>
>
> Hi Tony,
>
> The following command lists the local changesets not
> found in Bram's repository:
>
>      $ hg outgoing

yeah, meaning all my merges (quite a lot of them) and my few local
changes. In most cases I'm not interested in them. When discussing in
which build I had a bug, it's *Bram's* latest commit that I need, to say
(in a repeatable way) where that bug exists.

>
>
> I am managing some vim patches for pyclewn with the mq extension
> (Mercurial queues). The following simple command outputs the latest
> changeset made by Bram on which my patches are applied:
>
>      $ hg parents -r qbase
>      changeset:   2172:e12b9d992389
>      tag:         qparent
>      parent:      2170:cf8f86128f4c
>      user:        Bram Moolenaar<[hidden email]>
>      date:        Sun May 16 13:56:06 2010 +0200
>      summary:     updated for version 7.2.436
>
> Another advantage of using mq when applying patches, is that the patch
> changeset id is temporary: when you apply the patch to a more recent
> Bram's repository version, a new changeset id is created and the old
> one is forgotten.
>
>
> Xavier
>

I apply the patch only once, and rather than what apparently amounts to
rollback-pull-update-reapply-commit I use "hg fetch --switch-parent"
which, in essence, applies Bram's latest changes on top of what I was
already using. One advantage is that, if not touched by Bram's changes,
any files I once modified aren't mentioned anew in the history, so I can
be sure that they don't get patched again and don't look "new" to make.

This fetch extension is simple, I think I understand it, and it suits me
perfectly. I have taken a look at that mq extension and it gave me a
headache. It may be the right tool for you, for me it isn't.

So the following lets me know (in the "normal" case) what was Bram's
latest commit:

$ hg tip
changeset:   2211:5e352d198beb
branch:      vim73
tag:         tip
parent:      2209:94d29057b6a7
parent:      2210:014a996ac896
user:        Tony Mechelynck <[hidden email]>
date:        Wed May 19 23:11:58 2010 +0200
description:
Automated merge with https://vim.googlecode.com/hg/

The answer is 014a996ac896 (the most recent predecessor to this merge).
Or if I want to see what happened then, I can use almost the same
command as you did above:

$ hg parents -r tip
changeset:   2209:94d29057b6a7
branch:      vim73
parent:      2202:4d1344a67d4a
parent:      2208:e741fe7a0547
user:        Tony Mechelynck <[hidden email]>
date:        Wed May 19 02:05:18 2010 +0200
description:
Automated merge with https://vim.googlecode.com/hg/


changeset:   2210:014a996ac896
branch:      vim73
parent:      2208:e741fe7a0547
user:        Bram Moolenaar <[hidden email]>
date:        Wed May 19 21:57:45 2010 +0200
files:       runtime/doc/editing.txt runtime/doc/todo.txt
src/auto/configure src/blowfish.c src/config.h.in src/configure.in
src/netbeans.c src/sha256.c src/vim.h
description:
Use UINT32_T in the code, define it to uint32_t or unsigned int.
Better autoconf check for uint32_t.



Happy Vimming,
Tony.
--
It is impossible to make anything foolproof because fools are so
ingenious.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php