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

Re: Vim development process is utterly broken (Was: Re: [patch] test98 stops when using gvim)

Expand Messages
  • Marc Weber
    You can share topic branches or PatchBranchExtension . mq patches are your personal stack of patches only AFAIK. mq allows to reorder patches, pop/push
    Message 1 of 27 , Jul 16, 2013
      You can share "topic branches" or "PatchBranchExtension". mq patches are
      "your personal stack of patches" only AFAIK.

      mq allows to reorder patches, pop/push them.
      PatchBranchExtension is about managing patches which may depend on each
      other and sharing them, right?

      I've added this to the wiki.

      > [..]
      > use different commands, or sequences of them, to achieve a given result.
      Yes - but there is :h to document and talk about all of them :) So its
      not bad doing the same for Vim development workflows.

      Marc Weber

      --
      --
      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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Tony Mechelynck
      ... You can share them in diff format, just like the patches that I see on vim_dev. ... I don t know PatchBranchExtension. In mq, when patches depend on each
      Message 2 of 27 , Jul 16, 2013
        On 07/17/13 00:59, Marc Weber wrote:
        > You can share "topic branches" or "PatchBranchExtension". mq patches are
        > "your personal stack of patches" only AFAIK.

        You can share them in diff format, just like the patches that I see on
        vim_dev.

        >
        > mq allows to reorder patches, pop/push them.
        > PatchBranchExtension is about managing patches which may depend on each
        > other and sharing them, right?

        I don't know PatchBranchExtension. In mq, when patches depend on each
        other, you keep them in one "queue" which is pushed and popped like a
        stack. When they don't, you can put them in separate queues (with the hg
        qqueue command) and push/pop them independently of each other. So far,
        the Mozilla bugs I've fixed didn't require much coding (maybe a handful
        of lines in up to three files) so I never felt the need to divide the
        fixes for a single bug into several interdependent patches: typically my
        "queues" are of one patch each; you're making me remember that I can
        delete any of them which has made it into the official source. But I've
        seen bigger fixes written by others, with (rarely) up to 8
        interdependent patches that had to be pushed in a certain order.

        >
        > I've added this to the wiki.

        URL?

        >
        >> [..]
        >> use different commands, or sequences of them, to achieve a given result.
        > Yes - but there is :h to document and talk about all of them :) So its
        > not bad doing the same for Vim development workflows.

        Yes indeed: Vim is the only piece of software with a help worth its name
        that I've met since (when? in the eighties, maybe) I stopped working on
        mainframes where the documentation (for software that came with the
        machine) was a set of paper books (in quarto or US letter format, I
        think, and meant to be kept in three-ring binders) and where the source
        (in assembly language on half-inch 2400 ft tapes, and sometimes on
        assembly listings on zigzag paper 132 characters wide by 11 or 12
        inches, similar to "ledger" from what I see under :help popt-option) was
        there for anyone interested in it — most people weren't.

        I remember getting an interim job once after going to an "examination"
        where we had to write a COBOL program about a given problem. I went with
        the COBOL manual for my former computer, opened it in front of me on the
        table, and stuck to the "standard" (non-machine-specific) language as
        described in it. Some other examinees rebuked me for “cheating”, but I
        got the job. (“Cheating?” I said, “Aren't you /supposed/ to have the
        compiler manual at hand when writing a program?”).

        >
        > Marc Weber
        >
        Best regards,
        Tony.
        --
        The UNIX philosophy basically involves giving you enough rope to
        hang yourself. And then a couple of feet more, just to be sure.

        --
        --
        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

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Marc Weber
        ... I m talking about hg pull like sharing. ... still the same: http://vim-wiki.mawercer.de/wiki/vim-development/development.html The script below shows how
        Message 3 of 27 , Jul 16, 2013
          Excerpts from Tony Mechelynck's message of Wed Jul 17 03:45:35 +0200 2013:
          > You can share them in diff format, just like the patches that I see on
          > vim_dev.
          I'm talking about "hg pull" like sharing.

          > URL?
          still the same: http://vim-wiki.mawercer.de/wiki/vim-development/development.html


          The script below shows how you can have a topic branch, merge "default"
          into it by "hg pmerge", and still pull/push it. Try the same with mq,
          you'll end up in a mess (with distributed development)

          That's the main difference. Person B can fix bugs in the topic branch of
          Person A. Person C can develop a feature on top of that topic branch
          etc. Whether this is useful depneds on the use case - but you can push
          to bitbucket or the like.

          Marc Weber

          rm -fr test
          (
          set -x
          set -e
          mkdir -p test/source

          add_commit(){
          echo $1 > $1
          hg add $1
          hg commit -m $1
          }

          (
          cd test/source
          hg init .
          add_commit a
          hg pnew -t topic-msg topic

          # this will not show up, because its committed upstream below, see [up]
          add_commit topic-commit-1
          # these will end up in the topic diff
          add_commit topic-commit-2
          )

          # clone topic
          hg clone test/source test/clone


          (
          cd test/source
          hg update -C default
          add_commit upstream-change

          # let's make it more complicated, feed topic-commit upstream [up]
          add_commit topic-commit-1


          # add a third topic change:
          hg update -C topic
          add_commit topic-commit-3
          )

          (
          cd test/clone
          # now get updates of the topic branch by pull
          # and this is what I don't like, you cannot "preview" using mercurial ..
          # best you could do is make a backup of this repo before pulling ..
          # so this should get topic-commit-3 into the clone
          hg pull -u

          hg update -C default
          add_commit last
          hg update -C topic
          # merge this patch upstream
          hg pmerge

          # and this is the cool thing, you can just push the updated topic without
          # "diff" formats:
          hg push -b topic ../source
          )


          (
          # export (we don't have deps, but this would export topics on which this topic depneds, too)
          cd test/source
          hg update -C topic
          hg pexport -U 10
          )

          )

          --
          --
          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

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Ben Fritz
          ... Can you elaborate a little on the remotes feature you list on that page as being better in git? IIUC I *think* that is basically the same as the paths
          Message 4 of 27 , Jul 17, 2013
            On Tuesday, July 16, 2013 9:16:09 PM UTC-5, MarcWeber wrote:
            > Excerpts from Tony Mechelynck's message of Wed Jul 17 03:45:35 +0200 2013:
            >
            > > You can share them in diff format, just like the patches that I see on
            >
            > > vim_dev.
            >
            > I'm talking about "hg pull" like sharing.
            >
            >
            >
            > > URL?
            >
            > still the same: http://vim-wiki.mawercer.de/wiki/vim-development/development.html
            >

            Can you elaborate a little on the "remotes" feature you list on that page as being better in git?

            IIUC I *think* that is basically the same as the "paths" section in the hgrc, but with an interface to modify it.

            http://stackoverflow.com/questions/4956346/how-can-i-add-remote-repositories-in-mercurial

            TortoiseHg provides a GUI to add paths, but I don't know of any built-in command-line tools to do it.

            --
            --
            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

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          Your message has been successfully submitted and would be delivered to recipients shortly.