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

Re: [patch] Process Interaction support for Vim (unstable version)

Expand Messages
  • Markus Heidelberg
    ... Indeed! I used it, when I recently used git-bisect, since vim_extended doesn t have much useful history for Vim 7.1 ... No problem, this is what we are
    Message 1 of 19 , Mar 2, 2009
    • 0 Attachment
      Milan Vancura, 02.03.2009:
      > Similarly, if I need to check something in the vim history, another repository,
      > made by Christian Michon, is very helpful (http://github.com/cmichon/vim).

      Indeed! I used it, when I recently used git-bisect, since vim_extended
      doesn't have much useful history for Vim 7.1

      > So I want to thank Markus and Christian for their work here. Thank you, guys,
      > as you made my life easier!

      No problem, this is what we are born for :)

      Markus


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... Any such unofficial patch to runtime files will have to be reapplied after each and every rsync run. Possible, but not practical, and it could readily be
      Message 2 of 19 , Mar 2, 2009
      • 0 Attachment
        On 02/03/09 13:48, Milan Vancura wrote:
        >> Tony Mechelynck, 28.02.2009:
        >>> On 28/02/09 12:06, Markus Heidelberg wrote:
        >>>> Tony Mechelynck, 28.02.2009:
        >>>>> On 28/02/09 11:34, Markus Heidelberg wrote:
        >>>>> [...]
        >>>>>
        >>>>> This debate is going nowhere. You won't change your mind, and neither
        >>>>> shall I, so I'm shutting up.
        >>>> OK, do so, without having responded to the main argument a single time,
        >>>> although I've reminded you. It seems you are running out of arguments.
        >>>> Please put down your anti-git attitude and accept its usefulness,
        >>>> at least in the case of the runtime updates.
        >>>>
        >>>> Markus
        >>> What main argument?
        >> I didn't want to repeat it for the third time, but since you don't
        >> understand, here it is, copied from a former mail:
        >>
        >> It doesn't work for runtime changes, which you HAVE to put into existing
        >> files.
        >
        > I think everything is clear: StarWing has a problem and Markus suggested a
        > solution. The suggested solution not only works for StarWing but doesn't harm
        > anyone in his/her workflow. It allows the others to get a better patch from
        > StarWing on the vim_dev list (as the patch will be tested better) so it will be
        > a clear benefit for everyone.
        >
        > Users of vim_extended repository have a little advantage more: they can work
        > with the patch(set) more interactively, merge it with their patches, select
        > patches/branches to merge and test conflicts or a cooperation of several
        > features at once etc. All this can be done localy and, after the first tree
        > clone, offline. More about git advantages (and not only git, Mercurial is an
        > example of other VCS offering a similar level of usability; and there may be
        > others) was already said on this list some time ago. Just check the archive.
        > There you will see, Tony, that this is not any exception: James Vega maintains
        > a repository for Debian purposes, MacVim is maintained in a similar way as
        > well... There must be something good behind it :-)
        >
        > But even people using ftp+rsync method can achieve the same just using
        > different method (in a more complicated way, my opinion, but this is a
        > different story and not my decision) as everyone still gets a patch through the
        > vim_dev mailing list.

        Any such unofficial patch to runtime files will have to be reapplied
        after each and every rsync run. Possible, but not practical, and it
        could readily be avoided by avoiding placing any unofficial runtime
        files or runtime file changes in the $VIMRUNTIME tree. Wasn't I clear?

        >
        > This all is possible not only because of git but because of Markus's great work
        > on vim_extended repository which combines vim and runtime files together and
        > allows feature branches for testing.
        >
        > Similarly, if I need to check something in the vim history, another repository,
        > made by Christian Michon, is very helpful (http://github.com/cmichon/vim). I
        > know how hard was to work without its help, when, one time, I needed look to
        > vim 5.4 which is not included in Christian's repo and I did have to find
        > patches myself...
        >
        > So I want to thank Markus and Christian for their work here. Thank you, guys,
        > as you made my life easier!
        >
        > Milan


        Regards,
        Tony.
        --
        We ARE as gods and might as well get good at it.
        -- Whole Earth Catalog

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Markus Heidelberg
        ... The words not practical and readily be avoided from someone, who uses an ftp client, patch and rsync just to update a single software package? You can
        Message 3 of 19 , Mar 3, 2009
        • 0 Attachment
          Tony Mechelynck, 03.03.2009:
          > On 02/03/09 13:48, Milan Vancura wrote:
          > > But even people using ftp+rsync method can achieve the same just using
          > > different method (in a more complicated way, my opinion, but this is a
          > > different story and not my decision) as everyone still gets a patch through the
          > > vim_dev mailing list.
          >
          > Any such unofficial patch to runtime files will have to be reapplied
          > after each and every rsync run. Possible, but not practical, and it
          > could readily be avoided by avoiding placing any unofficial runtime
          > files or runtime file changes in the $VIMRUNTIME tree.

          The words "not practical" and "readily be avoided" from someone, who
          uses an ftp client, patch and rsync just to update a single software
          package? You can also use telnet to fetch emails.

          Let's recapitulate the normal solution and your broken solution for a
          last time, without considering git, but only the conventional way with
          ftp, patch and rsync. I hate writing so long mails and meanwhile I doubt
          you understand it after reading, but I will try anyway.
          For unofficial patches, not for plugins:

          Normal solution:

          - patches contain changes to the runtime files directly in the patch
          - so you have 1 patch file and nothing else

          - apply the patch with the patch tool

          - rsync would overwrite the changes a patch introduces
          - so reverse the patch
          - then update the official runtime files with rsync
          - and finally reapply the patch

          - convenient? not really, but you chose so with the ftp/patch/rsync
          workflow
          - automatable? yes, can be achieved easily with a script


          Broken solution:

          - patches only contain changes to the source files directly in the
          patch. Changes to the runtime files are done in separate files,
          preferably as a new file (e.g. for new documentation). But if it is
          not possible to use a new file, but necessary to adjust existing
          files, you copy and modify it for your patch.
          - so you have 1 patch file for the sources, some new files and some
          modified files

          - apply the patch with the patch tool
          - copy the new files into the right subdirectory of ~/.vim/
          - copy the modified files into the right subdirectory of ~/.vim/
          Since the files in this directory are loaded before the ones in
          $VIMRUNTIME, Vim uses the modified files instead of the unmodified
          without the changes

          - rsync wouldn't overwrite the changes a patch introduces, but if files
          are updated, which the patch has copied and modified, Vim will still
          use them. They contain the changes of the patch, but not the new
          changes from rsync
          - so update the official runtime files with rsync
          - somehow integrate the updates in your copied and modified files
          - maybe by creating a temporary patch between the old runtime files
          before the rsync updates and your modified runtime files
          - then copy the files you modified and were updated by rsync to ~/.vim/
          - finally reapply your temporary patch to the new copied files in ~/.vim/

          - convenient? not at all, even the first integration requires several
          steps to use the unofficial patch and is more complicated, because you
          have to deal with more than just 1 single patch file
          - automatable? yes, but requires more steps


          Conslusion:

          With the ftp/patch/rsync workflow, you have to care about the runtime
          files after the first integration of an unofficial patch in either ways.
          You have to use reapply tricks with patch to not lose changes, either in
          the official runtime files or in the runtime files changed by a patch.

          > Wasn't I clear?

          Yes, you was clear that you didn't get it and refused to learn.

          Markus


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        Your message has been successfully submitted and would be delivered to recipients shortly.