Bo Berglund wrote 11 lines
I have for many years now been using an install script to get the sources of fpc
and lazarus via svn based on the specific tags. Then the script installs the
needed dependencies and makes the complete installation on Raspberry Pi boxes.
Now I have two problems:
1) The svn server seems to be down so the source retrieval does not work
2) I cannot find any tutorial on how to proceed with modifications of scripts to
move from svn to gitlab.
Please advice how to:
1) Find which is the latest release tag of fpc and lazarus
Well I don't know your script, and I am not sure how exactly you do that in svn....
Also I do not know, if this is for a once up setup (so you only wont to download the one revision and nothing else), or if you don't mind. (I have not measured the overhead..>)
Most replies will be to clone all, and then look at tags. (or branches) But you can do ( -t => tags) https://git-scm.com/docs/git-ls-remote.html
git ls-remote -t https://gitlab.com/freepascal.org/lazarus/lazarus.git
However, there is on "svn serial rev number", nor a date. So you need to parse the "release version" number, and compare them.
If you have a complete clone, you can afaik sort them by "commit date" (see "git for-each-ref")
2) Retrieve the full sources for that tag on the command line
Again if you do not want to clone
git init .
git fetch --depth=1
https://gitlab.com/freepascal.org/lazarus/lazarus.git refs/tags/lazarus_2_2_0_RC1
git switch -c my-branch FETCH_HEAD
"my-branch" is your choice
*** the rest BELOW is completely UNTESTED / pure assumptions ***
I haven't tested how well updates work, if you go to other branches. Since you have no history fetched (depth =1), I expect a full download of any other version (unless it is a direct child / same branch, NOT diverged)
Git is written for getting the full history once. I *guess* (but might be totally wrong) that not doing so, will make you pay later. You could do a depth of 3000 or 10000.
That is 2.2.0 (with the ending 0) is likely less that 3000 commits divirged from main. Then that gives you common history, and 2.4 can base on that.
2.0.18 is probably more revisions from main.
If you only want to stay in the same fixes branch (and are ok with a new download for major releases) go with a depth of 500. It is unlikely that a release tag will be further away from its fixes branch (usual are 0 to 5 commits)
