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

Re: vim 7.3: A few problems with patches

Expand Messages
  • 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 1 of 12 , Jun 2, 2011
    • 0 Attachment
      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 2 of 12 , Jun 2, 2011
      • 0 Attachment
        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 3 of 12 , Jun 2, 2011
        • 0 Attachment
          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.