[fpc-other] How to modify install scripts when svn disappeared?

[Martin Frb]

On 11/08/2021 14:36, Bo Berglund via fpc-other wrote:
> 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)