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

69018Re: Runtime file updates [Was: Re: Typo in help file]

Expand Messages
  • Benjamin Fritz
    Apr 8, 2013
    • 0 Attachment
      On Friday, April 5, 2013 3:16:54 PM UTC-5, Bram Moolenaar wrote:
      > Ben Fritz wrote:
      > >
      > > I'd like to take this one step further. The runtime files are already
      > > largely maintained by people other than Bram. Bram, would you be
      > > opposed to using Mercurial to PULL changes to runtime files, from a
      > > separate public clone of the main Vim repository? Runtime file
      > > maintainers who like, could then maintain their files directly in a
      > > clone of the Vim repository and push to the "vim-runtime" repository
      > > whenever they have a version ready for release.
      > >
      > The current method is working quite well. There is not much overhead
      > for me. Only disadvantage is that you get ten updates at the same time,
      > every two weeks or so. I don't think the version history is interesting
      > enough that someone misses it.

      Obviously if it doesn't work for you, then it doesn't work.

      But, while the current method works great for you, it's not as nice for the

      Conceptually, all the runtime files are part of Vim. They should be
      maintainable within a clone of the Vim repository. New potential
      contributors who want to change something should be able to get a clone of
      the Vim repository and start hacking. If every maintainer works in their own
      little custom repository it causes headaches in merging later.

      If a maintainer DOES choose to edit their files in a clone of Vim's
      repostory, they face the problem that none of their commits will ever be an
      ancestor of any commits on trunk. So they will have their own personal
      branch forever. I've made my branch explicit in my clone for TOhtml to make
      things easier to keep track of, but it is still quite annoying when I go to
      make an update after a long absence, because I need to merge in a bunch of
      files from the default branch, even though the TOhtml files I'm pulling in
      are identical (minus timestamps).

      Finally, as Ingo points out, tracking what changed in any given runtime
      update is tricky. This would be easier if you could see the history. I DO
      think the history is interesting, and I don't think anything would be lost
      by showing it, "warts and all" as Mercurial types like to say. You would
      still presumably tag each C code update, and would pull/merge runtime
      updates in batches, so the "main" line of the default branch would remain
      much the same as it is now. The only difference is that runtime updates
      would have a second parent which could be examined to see what changed and

      > A new method with a repository has many new problems:
      > - How to control access to the public repository? Only the actual
      > maintainer must be allowed to check in changes. So we need a small
      > group of people to maintain the access rights.

      I was thinking that a small team of only a few people would control the
      public vim-runtime or vim-unstable or whatever repository. They get changes
      from maintainers on vim_dev and do a quick review before pushing to the
      repository. Maintainers could email files as they have been doing, but would
      be encouraged to set up a clone of the vim repository as well so that the
      vim-runtime admins can just pull the changes with Mercurial as well.

      > - What if the maintainer can't be reached? This happens a lot.

      This is a separate problem that happens now as well. I don't see using
      Mercurial causing any additional problems in this area. And it could make
      things better. Some maintainers might opt for a more team-maintenance mode
      for their files so that if they don't respond for a while, important patches
      like the 'cpo' handling can be applied without them. Other maintainers might
      drop out for a while, but will easily be able to see what changes have been
      made and against which version of their files when and if they come back.

      > - I still need to pull for changes once in a while, it is unlikely this
      > will happen more often than what happens now.

      That's OK. If users are interested in getting changes faster, they can pull
      them into their own private repository clone. Otherwise, they can wait for
      your blessing on a "stable" version. Right now there is no way for users to
      get changes faster unless the maintainer CCs vim_dev when sending you a new

      And I agree with Ingo here, I don't care as much about the speed of updates,
      as I care about being able to see quickly what happened in those updates.
      Currently when you push a set of revisions, I glance at the commit log for
      each C code change, but I then go into every runtime file of interest to me
      and examine the changes to figure out what happened there. You could make
      this a lot better by writing brief summaries of the content of those runtime

      Since Vim is already developed in Mercurial, I think it would be less work
      for you to just make the changelog of the runtime files visible to anybody
      interested in what changes were made and why.

      > - The version in the public respository will differ from what I have. I
      > often reject new files or new versions of a file because it contains
      > mistakes.

      It may differ somewhat, but if you make changes also in Mercurial those will
      be tracked as well. I presume you normally alert the maintainer if there are
      problems; the maintainer can fix them before you pull instead.

      > I think the advantage is theoretical only.

      I think the advantage is flexibility. Your workflow is working for a lot of
      people. Heck, it's actually working for me. I just think it could be a
      little better and a little smoother around the edges, and I think the
      community as a whole could benefit from Mercurial being used closer to its
      full potential.

      If you're still not open to the idea, I'll drop it now, but I thought I'd
      speak up while the subject was fresh again.

      And since I suppose I've hijacked Ingo's request, I'd also like you to
      consider at least adding a summary of changes for runtime updates, if you
      don't like the idea of pulling in all the development history.
      One-commit-per-update would also work if it had a succinct summary like the
      patch updates (but you don't need to send an email for each probably).

      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.
    • Show all 8 messages in this topic