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

Re: Vim version 7.1a BETA -- svn ?

Expand Messages
  • Edward L. Fox
    ... Well, currently the svn repository has no tags , branches and trunk , unlike most of the other svn repositories. But that s not because it s a mirror
    Message 1 of 11 , May 6, 2007
    • 0 Attachment
      On 5/7/07, François Pinard <pinard@...> wrote:
      > [Martin Krischik]
      > >> [Martin Krischik]
      >
      > >> > That is probalby because the svn server is a mess.
      > [probably]
      >
      > >Only the vim svn archive has no space for tags, braches or releases.
      > [branches]
      >
      > It is not a mess, merely being different. If there is ever a _real_
      > need for another organisation of the Subversion repository for Vim, we
      > can be fairly confident that it will be addressed.
      >
      > But now, the Subversion repository mirrors a non-Subversion one, this is
      > for users convenience, and that's very nice already. Bram currently
      > does not use Subversion for Vim development, so there is no point
      > pretending that he does. If Bram was using Subversion, he might feel
      > like changing things. But even then, the needs would mainly be Bram's!

      Well, currently the svn repository has no "tags", "branches" and
      "trunk", unlike most of the other svn repositories. But that's not
      because it's a mirror of a non-svn repository - cvs can also uses tags
      and branches. The main reason is, Bram doesn't use cvs for
      development, either. He maintains another repository internally. So
      both cvs and svn are doing the same thing as an ftp server.

      > >But you can do valuable service and still do it wrong [...]
      >
      > Once again, being different does not imply being wrong. We should not
      > be overly dogmatic in such matters. If the download recipes are clear
      > and work as expected, the repository fills its role.

      Yes. If once needed, we can create the needed "trunk", "branches",
      "tags" directories very simply with just a few commands. So just don't
      panic.

      >
      > --
      > François Pinard http://pinard.progiciels-bpi.ca
      >
    • Edward L. Fox
      ... Bram won t make such branches. He always commit patches linearly. If he one day can finally realize that how valuable the branches are, we ll create the
      Message 2 of 11 , May 6, 2007
      • 0 Attachment
        On 5/7/07, A.J.Mechelynck <antoine.mechelynck@...> wrote:
        > François Pinard wrote:
        > > [Martin Krischik]
        > >>> [Martin Krischik]
        > >
        > >>> > That is probalby because the svn server is a mess.
        > > [probably]
        > >
        > >> Only the vim svn archive has no space for tags, braches or releases.
        > > [branches]
        > >
        > > It is not a mess, merely being different. If there is ever a _real_
        > > need for another organisation of the Subversion repository for Vim, we
        > > can be fairly confident that it will be addressed.
        > >
        > > But now, the Subversion repository mirrors a non-Subversion one, this is
        > > for users convenience, and that's very nice already. Bram currently
        > > does not use Subversion for Vim development, so there is no point
        > > pretending that he does. If Bram was using Subversion, he might feel
        > > like changing things. But even then, the needs would mainly be Bram's!
        > >
        > >> But you can do valuable service and still do it wrong [...]
        > >
        > > Once again, being different does not imply being wrong. We should not
        > > be overly dogmatic in such matters. If the download recipes are clear
        > > and work as expected, the repository fills its role.
        > >
        >
        > Anyway, if the code mirrored on that svn server belongs only to the 7.0
        > (release) code tree, there are no branches, since every patchlevel comes
        > linearly on top on the one before, and there is one set of files applicable to
        > all platforms and featuresets.
        >
        > _If_ there comes a 7.0.244, _and_ it branches out from 7.0.243 away from
        > 7.1a.000 and 7.1a.001, _and_ both 7.0 and 7.1a are further mirrored on svn,
        > _then_ there will maybe be a reason to define a branch point. But not before.

        Bram won't make such branches. He always commit patches linearly. If
        he one day can finally realize that how valuable the branches are,
        we'll create the tags and branches directories in the svn directory
        right away. It only costs a few commands. :-)

        >
        > Best regards,
        > Tony.
        > --
        > Speer's 1st Law of Proofreading:
        > The visibility of an error is inversely proportional to the
        > number of times you have looked at it.
        >
      • Edward L. Fox
        ... I don t think so. I guess the reason why updates did not make it to svn was that the svn committer was out for holiday. Because the svn committing work has
        Message 3 of 11 , May 6, 2007
        • 0 Attachment
          On 5/6/07, Yakov Lerner <iler.ml@...> wrote:
          > On 5/6/07, Martin Krischik <krischik@...> wrote:
          > > Am Sonntag 06 Mai 2007 schrieb Yakov Lerner:
          > >
          > > > On 2007-05-05, Bram Moolenaar <Bram@...> wrote:
          > > > > Announcing: Vim (Vi IMproved) version 7.1a BETA
          > > >
          > > > I tried to build vim7.1 from svn. But all I get from usual
          > > > svn location (https://svn.sourceforge.net/svnroot/vim/vim7), is
          > > > vim 7.0.236. Will vim7.1 be served at this localtion eventually ?
          > >
          > > That is probalby because the svn server is a mess.
          >
          > I have to disagree. The svn maintainer does valuable service
          > to the community. The svn service is really stable, unlike the cvs server.
          > I'd like to really thank the svn updater for keeping the svn updated.
          >
          > The reason why updates did not make it to svn was that cvs
          > server was down, as Bram explained above.

          I don't think so. I guess the reason why updates did not make it to
          svn was that the svn committer was out for holiday. Because the svn
          committing work has nothing to do with the cvs service. It only
          depends on the ftp service: the committer checks out the patches from
          the ftp, not from cvs.

          >
          > Yakov
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.