Loading ...
Sorry, an error occurred while loading the content.
 

Re: vim 7.3: A few problems with patches

Expand Messages
  • Tony Mechelynck
    ... What do you see if you try making a new clone (besides your existing one, not immediately replacing it)? Or, are your logs up-to-date? If (after cd to your
    Message 1 of 12 , Jun 1, 2011
      On 01/06/11 19:40, sc wrote:
      > On Monday, May 30, 2011 03:35:34 you wrote:
      >
      >> On 30/05/11 02:16, sc wrote:
      >>> On Saturday, May 28, 2011 22:03:43 Birger J. Nordølum wrote:
      >>>> Ontopic: I were unable to apply the patches from the FTP
      >>>> server. It stopped at 202.
      >>>
      >>> the the :version after you build with what you got, or maybe
      >>> peek in src/version.c
      >>>
      >>> patch 202 was the last one to get tagged in hg, but 206 was
      >>> the last actual one in there
      >>>
      >>> sc
      >
      >> changeset 46544d3ae7ec dated Wed May 25 21:18:06 2011 +0200 by
      >> Bram Moolenaar<bram@...> has the tag v7-3-206, added by
      >> the next changeset (e9538cfd0d9c).
      >
      > i have neither of those changeset ids in any of my logs, and
      > no such tag in hg -- yet my hg insists there are "no changes
      > found" -- and what i build reports a version of 7.3.206
      >
      > curious
      >
      > sc
      >

      What do you see if you try making a new clone (besides your existing
      one, not immediately replacing it)?

      Or, are your logs up-to-date? If (after cd to your Vim repository) you do

      hg -v log -l 10

      these changesets (if you have them) should appear near the top of the list.


      Best regards,
      Tony.
      --
      Try to find the real tense of the report you are reading: Was it done,
      is it being done, or is something to be done? Reports are now written
      in four tenses: past tense, present tense, future tense, and
      pretense. Watch for novel uses of CONGRAM (CONtractor GRAMmer),
      defined by the imperfect past, the insufficient present, and the
      absolutely perfect future.
      -- Amrom Katz

      --
      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
    • Birger J. Nordølum
      Yes, I m aware. I see you are too :) IMHO, Google Code is perhaps a bit to old and none social for my likings. But I guess Mercurial and a stream of commits is
      Message 2 of 12 , Jun 2, 2011
        Yes, I'm aware. I see you are too :)

        IMHO, Google Code is perhaps a bit to old and none social for my likings. But I guess Mercurial and a stream of commits is better than none. Not used to the way the Vim source is handled there. Where the "patches" are applied when they are released, rather than being pushen when they occur. Making it much easier to follow development.

        So, your remark regarding DVCS, might not be fully true in this case. Because it's not used to develop on, just push already existing patches. Which from my point of view, is not using the full potentials of DVCS.

        Just my two cents.

        --
        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
      • sc
        ... indeed they do -- i see many updates that way that don t appear in my update log i guess my update (pull) needs a verbosity option thanx sc -- You received
        Message 3 of 12 , Jun 2, 2011
          On Wednesday, June 01, 2011 13:07:02 Tony Mechelynck wrote:

          > Or, are your logs up-to-date? If (after cd to your Vim
          > repository) you do

          > hg -v log -l 10

          > these changesets (if you have them) should appear near the top
          > of the list.

          indeed they do -- i see many updates that way that don't
          appear in my update log

          i guess my update (pull) needs a verbosity option

          thanx

          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
        • Tony Mechelynck
          ... The Vim way is that Bram has to approve anything that makes it into the official distribution. He probably has a private repository where he builds
          Message 4 of 12 , Jun 2, 2011
            On 02/06/11 16:13, Birger J. Nordřlum wrote:
            > Yes, I'm aware. I see you are too :)
            >
            > IMHO, Google Code is perhaps a bit to old and none social for my
            > likings. But I guess Mercurial and a stream of commits is better than
            > none. Not used to the way the Vim source is handled there. Where the
            > "patches" are applied when they are released, rather than being pushen
            > when they occur. Making it much easier to follow development.
            >
            > So, your remark regarding DVCS, might not be fully true in this case.
            > Because it's not used to develop on, just push already existing patches.
            > Which from my point of view, is not using the full potentials of DVCS.
            >
            > Just my two cents.

            The "Vim way" is that Bram has to approve anything that makes it into
            the "official" distribution. He probably has a "private" repository
            where he builds his patches, maybe with the help of the mq extension,
            and whence, after checking them, he pushes them to the "public"
            repository which is the only one we see, and where everyone has read
            access, but AFAIK only Bram has write access.

            A comparatively small project like Vim doesn't need anything more
            complicated. If you want to contribute fixes, you don't "hg push", you
            send a patch (possibly created by "hg diff" or "hg export"), which Bram
            may (or may not) decide to apply, then, perhaps after testing and even
            amending, to commit (on his private repo) and publish (by pushing to the
            public repo). The case is enormously different in a big project like
            e.g. Mozilla, where the sources for the various applications are held in
            a family of interwoven Mercurial repositories with a huge lot of code
            between them, and where quite a number of developers may push unrelated
            changesets almost simultaneously with no knowledge of each other's work.


            Best regards,
            Tony.
            --
            Contrary to popular belief, Unix is user friendly.
            It just happens to be selective about who it makes friends with.
            -- Dave Parnas

            --
            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
          Your message has been successfully submitted and would be delivered to recipients shortly.