Recent

Author Topic: FPC & Lazarus moving to gitlab  (Read 100169 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #15 on: June 23, 2021, 12:05:08 pm »
In the case of trunk, svn was effectively being used for distribution. I've seen Git being spectacularly incapable of filling the same role, e.g. with Mycroft where the /only/ way of running it is to have a complete repo clone.

there is a shallow clone

git clone --depth=1  url folder

Yes, I know: been using it for years. And I've seen projects- I gave an example- where that doesn't work.

Unless there is some way that the requirement that --depth=1 always delivers a valid snapshot can be "baked into" a project's Git configuration then there's a risk that sooner or later somebody will screw it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #16 on: June 23, 2021, 01:03:57 pm »
Yes, I know: been using it for years. And I've seen projects- I gave an example- where that doesn't work.
Ok, I missed that, actually googled it. Looks that it was a config fault by the project, or I found something else?
In any case errors happen with software.
SVN is not better. It does screws up for me... It does so, regularly when I switch the fpc-build between fixes and trunk. I got a script now, that remove all files, and does a new checkout. (I guess most people do not have that issue, but I am the unlucky one). So for me, git will hopefully fix an existing problem.

But to conclude, every change that happens in the world will be positive for some, and less good for others. The hope is that the amount of those benefiting will grossly outweigh the amount of those who don't.

We believe that this (more benefits) will be the case here.

El Salvador

  • Full Member
  • ***
  • Posts: 134
Re: FPC & Lazarus moving to gitlab
« Reply #17 on: June 23, 2021, 01:06:36 pm »
So Mantis will be disappear (or will be lock for history)?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #18 on: June 23, 2021, 01:07:11 pm »
So Mantis will be disappear (or will be lock for history)?

Disappear, its machine is end of life.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #19 on: June 23, 2021, 01:09:44 pm »
- On the other hand the .svn folder of my svn checkout is 918 MB.

Should be 300 or so. Probably an old repo that you don't regular vacuum.  (tortoisesvn a tick in the cleanup command).

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #20 on: June 23, 2021, 01:35:46 pm »
Yes, I know: been using it for years. And I've seen projects- I gave an example- where that doesn't work.
Ok, I missed that, actually googled it. Looks that it was a config fault by the project, or I found something else?
In any case errors happen with software.

The developers' attitude was that it was intentional, and that anybody getting the Python programs from the repository was expected to have the entire repo on their hardware. Since I was running it on a PC that was bearable (a "mere" 2.8Gb), I don't know whether anybody running it on target hardware that the project supplied or recommended (basically, either a Raspberry Pi or a system embedded in e.g. a car) would find themselves in the same situation.

I am not prepared to get into an argument with the FPC/Lazarus teams if they make a similar configuration choice, or screw things up and go defensive. I am still rankling over the breaking change to FileExists()... granted that it was documented, but I still feel it was handled very badly and doesn't reflect well on the project.

Quote
SVN is not better. It does screws up for me... It does so, regularly when I switch the fpc-build between fixes and trunk. I got a script now, that remove all files, and does a new checkout. (I guess most people do not have that issue, but I am the unlucky one). So for me, git will hopefully fix an existing problem.

But to conclude, every change that happens in the world will be positive for some, and less good for others. The hope is that the amount of those benefiting will grossly outweigh the amount of those who don't.

We believe that this (more benefits) will be the case here.

I respect your decision and am not trying to pressurise you to reverse it.

However from my POV I've spent a lot of the last 20 years tinkering with non-x86 based computers and even longer dealing with minority OSes, mostly because of company policy that they should be used because they were technically elegant and were more robust in the face of error or intrusion. While that has increased my skills in some areas it has meant that in others I'm somewhat "behind the curve", and I quite simply can't afford to spend time going off on any more tangents.

As somebody who is not a core developer and has no (immediate) need to use Git or a Git-oriented hosting service for anything other than getting a current (.zip) snapshot, continued involvement with Trunk is tangential to everything else that I'm trying to do. In particular, I am not prepared to get myself into a situation where some needed facility of Trunk suddenly turns out to be broken, where if I want it to be fixed I've got to triage the release history myself, and where I find I can't easily revert to an older version because the .lpi or .lfm format has changed and I need a working Trunk to massage it back to a compatible format.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC & Lazarus moving to gitlab
« Reply #21 on: June 23, 2021, 01:49:53 pm »
As somebody who is not a core developer and has no (immediate) need to use Git or a Git-oriented hosting service for anything other than getting a current (.zip) snapshot, continued involvement with Trunk is tangential to everything else that I'm trying to do. In particular, I am not prepared to get myself into a situation where some needed facility of Trunk suddenly turns out to be broken, where if I want it to be fixed I've got to triage the release history myself, and where I find I can't easily revert to an older version because the .lpi or .lfm format has changed and I need a working Trunk to massage it back to a compatible format.

You'd have to do the triaging with SVN as well cause you can't necessarily know what broke it. And bisecting such a revision is even more comfortable with Git, cause it provides commands for that (no more counting revisions by hand).

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #22 on: June 23, 2021, 01:58:53 pm »
You'd have to do the triaging with SVN as well cause you can't necessarily know what broke it. And bisecting such a revision is even more comfortable with Git, cause it provides commands for that (no more counting revisions by hand).

Yeah, but usually you take the weight of the revisions (e.g. makefile regenerations/minor edits or unrelated minor target changes) into consideration so that each side of the bisection has about equal "weight".

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC & Lazarus moving to gitlab
« Reply #23 on: June 24, 2021, 08:59:00 am »
You'd have to do the triaging with SVN as well cause you can't necessarily know what broke it. And bisecting such a revision is even more comfortable with Git, cause it provides commands for that (no more counting revisions by hand).

Yeah, but usually you take the weight of the revisions (e.g. makefile regenerations/minor edits or unrelated minor target changes) into consideration so that each side of the bisection has about equal "weight".

In all honesty: in those moments I've done a bisection with SVN (be it with FPC or at work), I've simply counted the number of revisions (or more precisely: used TortoiseSVN's "number of selected revisions"). Much faster, much easier than to "interpret" the contents of the commit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #24 on: June 24, 2021, 09:25:23 am »
In all honesty: in those moments I've done a bisection with SVN (be it with FPC or at work), I've simply counted the number of revisions (or more precisely: used TortoiseSVN's "number of selected revisions"). Much faster, much easier than to "interpret" the contents of the commit.

Which as I've said, is probably the main thing that bothers me. I note that Martin's doing some interesting work on tags... and I note obviously the amount of functionality that Git exposes which can be used (and abused) by maintainers. But for the moment at least the change is enough to push me off Trunk.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #25 on: June 24, 2021, 09:43:36 am »
In all honesty: in those moments I've done a bisection with SVN (be it with FPC or at work), I've simply counted the number of revisions (or more precisely: used TortoiseSVN's "number of selected revisions"). Much faster, much easier than to "interpret" the contents of the commit.

Maybe, if you can give it a manually established, cleaned set. I mostly bisected fpdoc/fcl-passrc in the last few years. It probably also depends on how complex your test is that exposes the issue (and mine involved several minutes of chm building and manually testing with the windows chm help).

Extra unattended builds only warm up the earth, but extra tests can be painful.
« Last Edit: June 24, 2021, 09:48:32 am by marcov »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #26 on: June 24, 2021, 01:02:31 pm »
Yeah, but usually you take the weight of the revisions (e.g. makefile regenerations/minor edits or unrelated minor target changes) into consideration so that each side of the bisection has about equal "weight".

Well, I've gone a similar, but 3rd way...

If (and only if) I knew the file/folder that likely caused the issue (i.e, a bug in SynEdit, likely caused by a commit to a SynEdit file).

I displayed a filtered log, and then visually picked the middle.
Or even read commit messages, and ignored "updated translations"

However, this is  "visually picked the middle" because revisions are not continuous in that filtered log. (So the svn advantage is gone).

Of course, this only works if the filtered list, is small enough....

----

But, since the "svn advantage is gone", that can be done in GIT too. I can display the filtered log. I can see the list, and pick the middle.



On the other hand, and here comes the real difference....

I have not yet done that, but I will most likely in future.

I can write a script (or I might adapt lazbuild for that) => to return an exit code, indicating if all was fine (testcase run and succeeded) or not.

And then I can give that script to git. And  can go, get my coffee, and git will bisect the revison without me doing any further work.

And if git does it all on its own, I do not care if the bisect need a few searches more or less.

(Yes, I can write a wrapper for svn too. But git already includes it)


devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: FPC & Lazarus moving to gitlab
« Reply #27 on: June 24, 2021, 01:33:51 pm »
Question ( minor, and maybe silly ) from a novice (I don't know much about Git on a desktop workstation, and nothing about Continuous Integration a.k.a. CI or Continuous Delivery a.k.a. CD ): will the same "tree" semantics be kept on GitLab (i.e. "trunk", "branches", tag on "fix_", ...) rather than "master", "develop", "mainstream", ...?
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #28 on: June 24, 2021, 01:59:21 pm »
will the same "tree" semantics be kept on GitLab (i.e. "trunk", "branches", tag on "fix_", ...) rather than "master", "develop", "mainstream", ...?

Not actually yet decided.
Also this decision may happen per team.

The current status is, that afaik both projects will keep (at least for some time to come) a development branch, that acts like the current trunk. (the name of it may be different or not).

Equally for now, the fixes branches will be kept, and merging will be done from development to fixes (as it has been sofar / actually, I have for Lazarus SVN seen some bug fixes made to fixes, and then go to trunk.... but in either case trunk (by any name) still  is the development branch.)

Yet the above does not exclude that feature branches could be used. That has happened in svn too.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC & Lazarus moving to gitlab
« Reply #29 on: June 24, 2021, 02:02:10 pm »
However, this is  "visually picked the middle" because revisions are not continuous in that filtered log. (So the svn advantage is gone).

More or less that is what I did too. I didn't really use revision values since I was mostly only interested in changes in certain dirs. 

Quote
Of course, this only works if the filtered list, is small enough....

I already have code that contains revision lists in tlists in the mergelogs. In such case a "middlepoint" (tlist[count div 2]) would be trivial.

Quote
But, since the "svn advantage is gone", that can be done in GIT too. I can display the filtered log. I can
see the list, and pick the middle.

All my scripts (mostly FPC TProcess based) and every other infrastructure is invalidated. Worse, git seems to want bash for nearly everything which makes scripting a pain on Windows, specially when multiple driveletters are involved.

I'm reluctant to do this all again, in case the gitlab thing doesn't work out in a few years, and we go back to hosted.

Quote
I can write a script (or I might adapt lazbuild for that) => to return an exit code, indicating if all was fine (testcase run and succeeded) or not.

And then I can give that script to git. And  can go, get my coffee, and git will bisect the revison without me doing any further work.

If the work was worth writing a bullet proof automate script for in the first place. It rarely is. (I shudder at writing a test for CHM integrity)

Quote
(Yes, I can write a wrapper for svn too. But git already includes it)

Yes. But the move invalidates more scripting, than these kind of limited use gadgets actually add. Instead we have to do with some pre-cooked gitlab pages.

Also, getting scripting crossplatform will be harder. I used FPC for that, but with GIT in special bash shells that will be harder.
« Last Edit: June 24, 2021, 02:10:31 pm by marcov »

 

TinyPortal © 2005-2018