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

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

Expand Messages
  • Milan Vancura
    ... 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
    Message 1 of 19 , Mar 2, 2009
    • 0 Attachment
      >
      > 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.

      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
      --
      Milan Vancura, Prague, Czech Republic, Europe

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • 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 2 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 3 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 4 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.