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
    ... Sry, fixed to: https://gist.github.com/ZyX-I/5561409 -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below
    Message 1 of 27 , Jul 15, 2013
    • 0 Attachment
      > ?! Where is my description on the main project page?
      Sry, fixed to: https://gist.github.com/ZyX-I/5561409

      --
      --
      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
      ... I have so far not been active enough in any open-source project to use the web-based tools for pull requests, so I admit ignorance in regard to how that
      Message 2 of 27 , Jul 15, 2013
      • 0 Attachment
        On Monday, July 15, 2013 12:27:03 PM UTC-5, ZyX wrote:
        > > > With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
        > >
        > > I view that as a good thing. You'll need to post anyway when you make an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has 12 pull requests, he probably won't want to monitor each repository to see if anything changes. So the pull requester must post to say "updated to fix XYZ". If the changes are immediately available in the email, the maintainer has less work left to do to get them.
        >
        > ?! You don’t need to post, you need to push to a proper branch and it will appear in PR automatically. AFAIR github does not bother notifying in this case, dunno about bitbucket, but it would be good thing to do (I mean, notify about push into PR).
        >

        I have so far not been active enough in any open-source project to use the web-based tools for pull requests, so I admit ignorance in regard to how that works. I have so far assumed it is mostly a streamlined way (with a nice interface) to do "please pull revision abc123 from my public repository at example.com/repo to get my changes for feature X". I.e. this is something that COULD be done manually but is more efficient with the GitHub/BitBucket interface.

        I may have overlooked the idea that the maintainer should be looking at their own repository frequently enough to see that there is a pending pull request.

        Nevertheless, I do NOT want to pull a PR which I assume has been reviewed completely, only to have a few recently-pushed changes "sneak in" without review. I do NOT want to monitor for updates to the pull request to know when a fix I request is complete, I want to be told "hey, I fixed that issue you found in review, try again". I do NOT want to do the pull request, then go to publish the result, only to discover that some last-minute changes were made after my pull and need to pull again.

        Maybe it is just my ignorance showing; maybe the GitHub/BitBucket pull request concept is good enough to handle all that, but it seems like a good way to accomplish these things is a simple email to the list or maintainer saying "I updated pull request with revision abc123def to fix Jane Doe's review findings, it should be ready again".

        And not everybody has or wants a GitHub account. I think email submissions are still good, for small changes at the very least.

        My point was that it should be just as easy to say "I updated to fix Jane Doe's review findings, see attached bundle". Or even "see attached patch based off version 123fe56 in the main repo". With the bundle there is less opportunity for error than the patch.

        --
        --
        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.
      • Nikolay Pavlov
        ... (common for emailed bundles and diff). ... an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has
        Message 3 of 27 , Jul 15, 2013
        • 0 Attachment


          On Jul 15, 2013 11:22 PM, "Ben Fritz" <fritzophrenic@...> wrote:
          >
          > On Monday, July 15, 2013 12:27:03 PM UTC-5, ZyX wrote:
          > > > > With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
          > > >
          > > > I view that as a good thing. You'll need to post anyway when you make an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has 12 pull requests, he probably won't want to monitor each repository to see if anything changes. So the pull requester must post to say "updated to fix XYZ". If the changes are immediately available in the email, the maintainer has less work left to do to get them.
          > >
          > > ?! You don’t need to post, you need to push to a proper branch and it will appear in PR automatically. AFAIR github does not bother notifying in this case, dunno about bitbucket, but it would be good thing to do (I mean, notify about push into PR).
          > >
          >
          > I have so far not been active enough in any open-source project to use the web-based tools for pull requests, so I admit ignorance in regard to how that works. I have so far assumed it is mostly a streamlined way (with a nice interface) to do "please pull revision abc123 from my public repository at example.com/repo to get my changes for feature X". I.e. this is something that COULD be done manually but is more efficient with the GitHub/BitBucket interface.
          >
          > I may have overlooked the idea that the maintainer should be looking at their own repository frequently enough to see that there is a pending pull request.
          >
          > Nevertheless, I do NOT want to pull a PR which I assume has been reviewed completely, only to have a few recently-pushed changes "sneak in" without review. I do NOT want to monitor for updates to the pull request to know when a fix I request is complete, I want to be told "hey, I fixed that issue you found in review, try again". I do NOT want to do the pull request, then go to publish the result, only to discover that some last-minute changes were made after my pull and need to pull again.

          Normally on both sides are reasonable people. One does not say PR is finished and add a new commit after this without notification unless he knows for sure when review is done. Though there also is a problem in github: I have same reasons to expect it to notify about changes, but it does not. Hope bitbucket does, but this needs to be tested.

          > Maybe it is just my ignorance showing; maybe the GitHub/BitBucket pull request concept is good enough to handle all that, but it seems like a good way to accomplish these things is a simple email to the list or maintainer saying "I updated pull request with revision abc123def to fix Jane Doe's review findings, it should be ready again".

          I did the same by posting to PR if I expected other side to miss changes (normally always after review had happened due to lack of notification). There now seems to be no advantage with github.

          Bitbucket has approve button in PR, but pushing new changeset does not alter approval status. It also does not notify about any changes as I run PR from one my repository to the other and as I approve myself and also push changes by myself the actual problem may be that it tries to be smart and thus changes pushed by approver just do not alter approval status. Second person is needed for the test. It did not automatically add changes to PR in my simple test though.

          Github does not have support for approving PRs.

          > And not everybody has or wants a GitHub account. I think email submissions are still good, for small changes at the very least.

          I actually do not want it on github, I would want it on bitbucket assuming it has comparable features. But as it being not so popular I have no experience with collaborative development there and cannot evaluate pros and cons for sure. Issue tracker is much better on bitbucket.

          > My point was that it should be just as easy to say "I updated to fix Jane Doe's review findings, see attached bundle". Or even "see attached patch based off version 123fe56 in the main repo". With the bundle there is less opportunity for error than the patch.
          >
          > --
          > --
          > 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.
          >
          >

          --
          --
          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.
           
           
        • Bram Moolenaar
          ... Wasn t there a reason these commands were in a separate file? As mentioned before, we should have a test for the tests... -- Back off man, I m a scientist.
          Message 4 of 27 , Jul 15, 2013
          • 0 Attachment
            Yukihiro Nakadaira wrote:

            > How about this?
            >
            > I guess the key is ":setl scb | wincmd p", executing these two command
            > in one normal_cmd() session.

            Wasn't there a reason these commands were in a separate file?

            As mentioned before, we should have a test for the tests...


            --
            Back off man, I'm a scientist.
            -- Peter, Ghostbusters

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.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

            ---
            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.
          • Yukihiro Nakadaira
            ... I think that the separate file was used for same purpose. -- Yukihiro Nakadaira - yukihiro.nakadaira@gmail.com -- -- You received this message from the
            Message 5 of 27 , Jul 16, 2013
            • 0 Attachment
              On Tue, Jul 16, 2013 at 5:17 AM, Bram Moolenaar <Bram@...> wrote:

              Yukihiro Nakadaira wrote:

              > How about this?
              >
              > I guess the key is ":setl scb | wincmd p", executing these two command
              > in one normal_cmd() session.

              Wasn't there a reason these commands were in a separate file?

              As mentioned before, we should have a test for the tests...

              I think that the separate file was used for same purpose.

              --
              Yukihiro Nakadaira - yukihiro.nakadaira@...

              --
              --
              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.
               
               
            • Bram Moolenaar
              ... Sorry, I don t understand what you mean with same purpose . -- For large projects, Team Leaders use sophisticated project management software to keep
              Message 6 of 27 , Jul 16, 2013
              • 0 Attachment
                Yukihiro Nakadaira wrote:

                > On Tue, Jul 16, 2013 at 5:17 AM, Bram Moolenaar <Bram@...> wrote:
                >
                > >
                > > Yukihiro Nakadaira wrote:
                > >
                > > > How about this?
                > > >
                > > > I guess the key is ":setl scb | wincmd p", executing these two command
                > > > in one normal_cmd() session.
                > >
                > > Wasn't there a reason these commands were in a separate file?
                > >
                > > As mentioned before, we should have a test for the tests...
                >
                > I think that the separate file was used for same purpose.

                Sorry, I don't understand what you mean with "same purpose".

                --
                For large projects, Team Leaders use sophisticated project management software
                to keep track of who's doing what. The software collects the lies and guesses
                of the project team and organizes them in to instantly outdated charts that
                are too boring to look at closely. This is called "planning".
                (Scott Adams - The Dilbert principle)

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ an exciting new programming language -- http://www.Zimbu.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

                ---
                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
                ... By a patch I mean what can serve as input to one run of the patch program, or what can become one new Mercurial changeset. In my mind, one patch can
                Message 7 of 27 , Jul 16, 2013
                • 0 Attachment
                  On 07/15/13 16:31, ZyX wrote:
                  > I would vote against any development process that uses patches, be it current one, suggested two-eye system or anything else.
                  >
                  > The two-eye system looks reasonable, but it should be applied to PR’s (commit series requested for inclusion as a whole) and not patches:

                  By "a patch" I mean what can serve as input to one run of the "patch"
                  program, or what can become one new Mercurial changeset. In my mind, one
                  "patch" can include several (related) changes to different files, meant
                  to be pushed together. See for example most patch-type attachments to
                  bug reports at bugzilla.mozilla.org. Every patchlevel of Vim
                  (corresponding currently to one line each after line 28 of
                  ftp://ftp.vim.org/pub/vim/unstable/patches/7.4a/README ) is what I call
                  "one patch".
                  This is not like what you can do online at github, where it is not
                  possible to modify several files in one commit, except by doing it in a
                  clone on your HD then pushing over SSL (requiring a GPG passphrase, and
                  I've forgotten mine), and where future bugfixes are committed as real
                  changesets into "side branches" ("branches" in the git sense) of an
                  online clone. At Mozilla, each patch (a diff of one or more files as
                  kept in .hg/patch* by the mq extension) gets attached as a unified diff
                  in git format to the concerned bug. A later version of a patch (in diff
                  format) may "obsolete" a previous one; then when the final version of a
                  patch has received the necessary reviews (and possibly superreview,
                  approval, etc.) the patch author (who is often not a member of the
                  select group of people which push access to the Mercurial repo) sets the
                  "checkin-needed" keyword on the bug, and someone else, maybe a Mozilla
                  employee or volunteer, but with push access, who periodically runs a
                  search for open bugs having that keyword, will import that patch into
                  his own clone (using the mq extension), check that it applies cleanly,
                  that it has the necessary metadata (e.g. an author name, a Subject
                  starting with a bug number, the names or IRC nicks of who gave the r+
                  (review) and maybe ui-r+ (UI review), sr+ (superreview) and/or a+
                  (approval) checks, etc. Then if the patch is OK he will commit it, for
                  SeaMonkey or Thunderbird to the comm-central repo, for Firefox often to
                  the mozilla-inbound repo, which gets merged into the mozilla-central
                  repo maybe once a day or so, when "the tree is green", i.e., the code
                  currently committed not only compiles and links, but passes all
                  automatic tests on all platforms (Win32, Lin32, Lin64 and Mac-Universal).

                  >
                  >
                  > This is how we can protect from partial application of the patch and any possible problems with encoding, empty files or whatever which may happen on reviewers machines. Pulling is more predictable, mercurial is known to pull or, in rare cases, not to pull (e.g. when there are problems with plugins, enabled on server, but not on client or too old mercurial version on one side) without any possible states in between.

                  To address the possibility of bit-rot, the patch author should refresh
                  his clone before every change, as well as when requesting
                  checkin-needed. Use of the mq extension to Mercurial is IMHO strongly
                  recommended, so that a patch can be developed, compiled, tested, and yet
                  popped off the clone when desired (e.g. while pulling updates from the
                  master repo).

                  I also use the mq extension to import patches written by others which I
                  want to test, so that no patch pollutes my clone's history before I've
                  decided that I like it enough to commit it onto my unnamed side branch
                  (in the Mercurial sense, of course; a "branch" in the git sense would be
                  a "bookmark" on Mercurial) of local changes (as I did for "extended"
                  floating-point behaviour before it finally became part of Bram's Vim).
                  At the moment my only local changes are a few additions to .hgignore
                  (for instance my shadow directories, my cscope.out, and anything ending
                  in .log) and a couple of changes to src/feature.h (in order to compile
                  with -tag_old_static and +xterm_save, as there is no configure setting
                  about these).

                  >
                  > This is how we can protect from false commit messages (like the one where I was blamed for fixing some two problems in python tests while I actually said the opposite: these two problems are the only ones that are still not fixed). Patches do not have messages attached. Messages from Bram are also known to constantly include bits of information which seem not essential for me and omitting essential ones. It does not mean they are always inessential and Bram is completely wrong: e.g. pyeval() has proved to be more useful then I though when writing it, though vim.bindeval seemed more essential. But I have more details for this reason and they are always omitted.

                  Since the mq extension places the commit message at the top of the patch
                  (in what the manual for the patch program calls the "leading garbage"),
                  the text of the message can be checked by eyeballing the patch text, and
                  if necessary corrected by hg qrefresh -m 'new text' before the patch is
                  committed into the repo, and frozen in bronze as one more changeset.

                  >
                  > Word about keeping context and seeing whether patch can be automatically merged was already said.
                  >
                  > This also enables normal annotate and log: with current commit messages format almost every bit of useful data is stripped from annotate and log (without -v) output: no user, shortened commit message is useless as it says only about vim version. Problem/solution is too verbose, no summary in the first line. Most developers will write this in their messages thus these features will work regardless of what is written in the merge message.

                  I wouldn't know; I have verbose=true in the [ui] section of my ~/.hgrc.
                  I have also set "log" and "annotate" (among other hg commands) to
                  default to being paged (using the pager extension) and BTW my default
                  pager for hg output is 'view -'. ;-)

                  >
                  > This is also how one can easily see which parts were included by Bram unmodified and which ones were modified (e.g. to fit coding style). This makes me learn about what should I be aware of when writing patches.
                  >
                  >
                  > I cannot say what are the advantages for Bram regarding simplicity of the process without knowing how he does his job, but with PR’s at least problems with omitting parts of the patches and noise about wrong commit messages will go away. In addition to noise about not using DVCS as DVCS and broken development process. I cannot think of any sanely written script that may modify my patch to leave one parenthesis as-is (like it was done recently), thus I assume 1. job of applying patches is done manually and 2. manually taking patches out of the messages is hard enough to apply smaller ones by hand. Do not know about bitbucket (did not ever received PR’s here), but with github (assuming Bram does not want to switch context from mailer to browser) merging basically is “copy command from email message to shell and run it”. Reviewing the diff is “open URL (under ‘Patch links’ section) in Vim and review” (since vim is capable for opening https:// links). I hope bitbucket ha
                  s something like this.
                  >

                  Best regards,
                  Tony.
                  --
                  BLACK KNIGHT: I'm invincible!
                  ARTHUR: You're a looney.
                  "Monty Python and the Holy Grail" PYTHON (MONTY)
                  PICTURES LTD

                  --
                  --
                  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
                  ... http://vim-wiki.mawercer.de/wiki/vim-development/development.html - keeping your own work up to date talks about topgit and PatchBranchExtension (hg)
                  Message 8 of 27 , Jul 16, 2013
                  • 0 Attachment
                    > checkin-needed. Use of the mq extension to Mercurial is IMHO strongly
                    > recommended, so that a patch can be developed, compiled, tested, and yet
                    > popped off the clone when desired (e.g. while pulling updates from the
                    > master repo).
                    http://vim-wiki.mawercer.de/wiki/vim-development/development.html
                    -> "keeping your own work up to date" talks about topgit and
                    PatchBranchExtension (hg) which are alternatives to mq.

                    They allow exporting a final commit based on the history of a topic
                    branch into which master/head got merged multiple times.

                    Well - at least its my preferred way :)

                    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.
                  • Yukihiro Nakadaira
                    ... To execute :setl scb and :wincmd p in one normal_cmd() session. It can be :source, :function, or bar. -- Yukihiro Nakadaira -
                    Message 9 of 27 , Jul 16, 2013
                    • 0 Attachment
                      On Wed, Jul 17, 2013 at 5:29 AM, Bram Moolenaar <Bram@...> wrote:

                      Yukihiro Nakadaira wrote:

                      > On Tue, Jul 16, 2013 at 5:17 AM, Bram Moolenaar <Bram@...> wrote:
                      >
                      > >
                      > > Yukihiro Nakadaira wrote:
                      > >
                      > > > How about this?
                      > > >
                      > > > I guess the key is ":setl scb | wincmd p", executing these two command
                      > > > in one normal_cmd() session.
                      > >
                      > > Wasn't there a reason these commands were in a separate file?
                      > >
                      > > As mentioned before, we should have a test for the tests...
                      >
                      > I think that the separate file was used for same purpose.

                      Sorry, I don't understand what you mean with "same purpose".

                      To execute ":setl scb" and ":wincmd p" in one normal_cmd() session.
                      It can be :source, :function, or bar.

                      --
                      Yukihiro Nakadaira - yukihiro.nakadaira@...

                      --
                      --
                      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
                      ... I guess you came to Mercurial from git (correct me if I m wrong): this merged multiple times business sounds like what happens at github. Me, on the
                      Message 10 of 27 , Jul 16, 2013
                      • 0 Attachment
                        On 07/17/13 00:07, Marc Weber wrote:
                        >> checkin-needed. Use of the mq extension to Mercurial is IMHO strongly
                        >> recommended, so that a patch can be developed, compiled, tested, and yet
                        >> popped off the clone when desired (e.g. while pulling updates from the
                        >> master repo).
                        > http://vim-wiki.mawercer.de/wiki/vim-development/development.html
                        > -> "keeping your own work up to date" talks about topgit and
                        > PatchBranchExtension (hg) which are alternatives to mq.
                        >
                        > They allow exporting a final commit based on the history of a topic
                        > branch into which master/head got merged multiple times.
                        >
                        > Well - at least its my preferred way :)
                        >
                        > Marc Weber
                        >
                        I guess you came to Mercurial from git (correct me if I'm wrong): this
                        "merged multiple times" business sounds like what happens at github. Me,
                        on the contrary, I've come to master Mercurial fairly well, but git,
                        when I have to use it (e.g. for projects whose source is held at github)
                        always seems foreign to me. With mq, you qpush a diff-format patch (on
                        top of the current changeset, usually the tip) when you're working on
                        it, you qrefresh and qpop it when you temporarily aren't, and anything
                        that you pull -u from the master repo in the meantime doesn't need to be
                        "merged" with it: the next time you qpush, the patch will be pushed onto
                        the new tip (and I'm not sure what happens in case of bit-rot since I've
                        never had the case).

                        Well, /de gustibus and coloribus non est disputandum/ — one shouldn't
                        quarrel about differences in taste. In Vim also, different people will
                        use different commands, or sequences of them, to achieve a given result.


                        Best regards,
                        Tony.
                        --
                        "If I believed in a god, which I do not, I would like to
                        communicate with him on the same intellectual level.
                        Therefore, I would have to teach him a few things."
                        [Aaron Erwin]

                        --
                        --
                        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
                        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 11 of 27 , Jul 16, 2013
                        • 0 Attachment
                          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 12 of 27 , Jul 16, 2013
                          • 0 Attachment
                            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 13 of 27 , Jul 16, 2013
                            • 0 Attachment
                              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 14 of 27 , Jul 17, 2013
                              • 0 Attachment
                                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.