Re: svn

[Dr . Jürgen Sauermann]

    Hi,
      
      I am using a two-step approach in maintaining GNU APL. It uses
       2 different SVN servers, one local SVN server located on my local
      LAN,
      the other somewhere else (at savannah.org).
      
      1. The first step is committing changes from my local build
      machine to the local SVN server.
      I work rather incrementally and therefore the commit rate is
      fairly high. The current SVN version
      on my local server is around 17800 and the small increments that I
      produce are mostly irrelevant
      for others but helpful for myself to revert broken developments.
      
      2. The second step is to export a local SVN version into the
      savannah SVN server. This step is
      performed less often, usually after a bug fix or after a major
      software change. The savannah SVN
      server currently is at SVN version 1440, so that statistically
      there is one second step per 12 first
      step.
      
      There is a file called "exported_from" in the savannah SVN repo
      that tells me from which local
      SVN version a particular savannah SVN version was created so that
      I can re-create the software
      status that a GNU APL user fetching from savannah has on her
      machine without the need to
      fetch it back from savannah (which would be slower).
      
      3. Now comes git, which, of course breaks it all. When GNU APL
      )SAVEs a workspace then it
      stores the SVN version of the interpreter (more precisely: the SVN
      version of Archive.cc) in the
      .xml file of the workspace. That allows us to restore the exact
      software version which has )SAVEd
      the workspace so that we will be able to )LOAD the workspace at
      any later point in time even if
      the interpreter(-binary) that has )SAVEd the workspace was lost in
      the meantime.
      
      This scheme works fine as long as only one SVN server is involved.
      If you fetch GNU APL from
      savannah, then your interpreter (and thos of other users with the
      same interpreter) can exchange
      their workspaces and will get a warning if their Archive.cc
      versions differ.
      
      GIt breaks this in a way because the git hashes are not linear (so
      you cant tell which one is older),
      or how far the git versions differ. In order to fix this problem,
      if you fetch GNU APL with git rather
      than with SVN, then your build shouldl tell you that your checkout
      is not SVN and it should then
      use the buildtag that was checked out (and supposedly has the SVN
      number from my local SVN
      server instead of the SVN number of the savannah server).
      
      This does NOT mean that git has NOT fetched the
      latest SVN version, but merely that the
      repository was not fetched with SVN but with git. If you had used
      SVN instead of git then you
      would have received exactly the same files and the only difference
      is that the checked-out
      version now has a SVN version number. As a matter of fact, under
      the hood there is only one
      real repository, and SVN and git are only two different front ends
      to it. And the difference in
      number only reflects that the numbers came from two different SVN
      servers.
      
      Normally multiple SVN servers are set up differently (so that
      their numbers are in sync), but I am
      lacking the permissions on savannah to do that.
      
      Hope this explains it,
      Jürgen

On 3/22/21 12:42 AM, Peter Teeson wrote:

> When APL starts it displays the Welcome page which lists the purported svn.
>
> If it displays an incorrect one then the natural assumption is that the git clone did not download the latest svn.
> That’s what I thought when I did the test to verify your Quad Plot syntax error. 
>
> Doesn’t seem benign to me.
>
> > On Mar 21, 2021, at 6:14 PM, John Helm <jhelm@usa.net> wrote:
> >
> > Yes, Peter. That's true and benign. ./configure calls ./src/buildtag, which attempts to run svn commands to get the version number and build a version string for apl to display on start-up. Since svn is not there, buildtag punts and uses an the tag that was obtained last time svn was present on a build machine. This shouldn't affect the build, just what version apl thinks it is. BTW, I installed svn for one of my High Sierra attempts; this message went away, but none of the other issues did. /John
> >
> > On 3/21/21 4:05 PM, Peter Teeson wrote:
> > > is not a svn checkout:
> > >         
> >       
>