Does this mean that it will no longer be possible to refer to a particular stage of trunk development as "revision such-and-such", and to step forwards and backwards from that point using a contiguous sequence of revision numbers?
MarkMLl
The Free Pascal and Lazarus teams are in the process of switching to Gitlab to manage their source code and issue reports.10MB ought to be enough for anybody (http://gitlab.com/gitlab-org/gitlab/-/issues/20061), yeah.
Does this mean that it will no longer be possible to refer to a particular stage of trunk development as "revision such-and-such", and to step forwards and backwards from that point using a contiguous sequence of revision numbers?
MarkMLl
This? (https://stackoverflow.com/questions/4120001/what-is-the-git-equivalent-for-revision-number)
Does this mean that it will no longer be possible to refer to a particular stage of trunk development as "revision such-and-such", and to step forwards and backwards from that point using a contiguous sequence of revision numbers?Mainly, yes.
Does this mean that it will no longer be possible to refer to a particular stage of trunk development as "revision such-and-such", and to step forwards and backwards from that point using a contiguous sequence of revision numbers?Mainly, yes.
The exact details on the below are still being evaluated. Outcome not yet known....
There will be options with "git describe", and such give you a way to refer to a commit in a way that tells you N commits after named known point.
If you do have a commit, you can walk to its parents easily (but not its children)
SOME_HASH_OR_NAME~1
the number gives how many parents up.
In that case I'm abandoning trunk. Git is indisputably an adequate tool for collaborative work, it's not suitable for software distribution.
The Free Pascal and Lazarus teams are in the process of switching to Gitlab to manage their source code and issue reports.10MB ought to be enough for anybody (http://gitlab.com/gitlab-org/gitlab/-/issues/20061), yeah.
In that case I'm abandoning trunk. Git is indisputably an adequate tool for collaborative work, it's not suitable for software distribution.
In that case I'm abandoning trunk. Git is indisputably an adequate tool for collaborative work, it's not suitable for software distribution.There must be a misunderstanding from your side.
In that case I'm abandoning trunk. Git is indisputably an adequate tool for collaborative work, it's not suitable for software distribution.There must be a misunderstanding from your side.
SVN was not used for software distribution either. It is for revision control and used by people who are interested in the project's development and/or participating in it.
Git is used for the same purpose.
Releases will be distributed as before.
A sequential revision number is gone, thus it will be useful to list date/time together with a hash ID.
Mentioning the hash ID, date/time, author and commit message of a revision gives enough information for any purpose.
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.
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.Ok, I missed that, actually googled it. Looks that it was a config fault by the project, or I found something else?
So Mantis will be disappear (or will be lock for history)?
- On the other hand the .svn folder of my svn checkout is 918 MB.
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.
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).
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.
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.
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".
will the same "tree" semantics be kept on GitLab (i.e. "trunk", "branches", tag on "fix_", ...) rather than "master", "develop", "mainstream", ...?
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.
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.
(Yes, I can write a wrapper for svn too. But git already includes it)
"master"
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.What "shell" are you currently using?
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.This is nothing to do with gitlab, but with git.
I don't quite follow, including I am not sure about what is current, and what is future.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.
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.What "shell" are you currently using?
git is callead as a command/exe.
I have used it from
cmd => so very seldom, because I dislike cmd.
the shell that came with git-for-windows
This is nothing to do with gitlab, but with git.
If we moved svn to be hosted by sourceforge, it still be svn.
[Of course existing scripts (or fpc apps) that call svn, must be changed to call git, and they must be adapted to the new syntax, the new output, and maybe the concept.
That is a once off for git.
re git is to call a script or program (like in bisect) that can be an fpc program. Or a script that first builds the fpc app, and the calls it.
As said, my experiences with bash shells on Windows is bad (even though I'm a 26 years long sh/Bash user). You can't copy paths from the explorer any more (due to \ vs /), driveletters require special handing, quoting rules etc are different etc.
And does git properly understand driveletters ?
True. The example was bad. It was just a remark about not wanting to invest heavily again, since this might also be temporary again. For windows users doubly so, since the degree to which git+associated tools are ported to Windows might vary over time.s/git/svn/ => and the statement is either as likely as, or even more worrying.
Yes. Every done investment is void. The more complex ones are in the FPC release and fixes branch maintenance realm though, which will now be done by Florian. So I won't have to redo them.
So you agree?Quote...Of course existing scripts (or fpc apps) that call svn, must be changed ...It was a one of for subversion too at one point :-)
That is a once off for git.
If git passes things like drivelettes and paths consistently yes. Otherwise you have to hack around that again, to interpret /drive/c etc.See initial part of my answer.
I've had some extremely bad experiences with this in the FPC early years with cygwin gdb.
The only sane solution is to minimize the use and so usually that means that things like compelex scripting are out
But at least in the GDB case there was no choice. Now we are leaving a perfectly windows integrated tool for one that is not.
Well, if run from cmd then yes, as far as I tested.
If run from a unix like sh/bash/... then no.
First of all, git expects to be run inside the repro dir (can be in a subdir, but not outside). At least afaik.
So most of the time you switch into that dir first.
QuoteTrue. The example was bad. It was just a remark about not wanting to invest heavily again, since this might also be temporary again. For windows users doubly so, since the degree to which git+associated tools are ported to Windows might vary over time.s/git/svn/ => and the statement is either as likely as, or even more worrying.
This is why
I think the fact that any software might cease to exist (entirely or partly) is not an argument (unless there are actual signs that it is about to happen.)
Here we could same as good say, Windows users may have a problem, because Windows may cease to exist (it already has a subsystem for linux, it may just drop the system around it, and be linux in itself...) ;)
Yes, that is the nature of change. It usually requires investment. And if it is done correctly, in the end the benefits will be more than the cost.
However, the distribution of benefits and cost is not always fair. Some loose out, some win. The aim is that the amount of winners is massively higher.
QuoteSo you agree?Quote...Of course existing scripts (or fpc apps) that call svn, must be changed ...It was a one of for subversion too at one point :-)
That is a once off for git.
I guess you talk about the CVS to SVN?
So did the change for fpc turn out to be good? Or would it be better, if fpc was still using cvs?
[…] The Free Pascal and Lazarus teams are in the process of switching to Gitlab to manage their source code and issue reports. […]That’s great news! Kudos to all that are involved in the migration process, writing and testing migration scripts and, let’s not forget, dealing with the non-technical issues.
[…] Statement of fact: I've got too much else on my plate to be prepared to continue with trunk since the change will involve learning a new toolset. Sorry.That’s fair. I mean, “we”, collectively as the FPC project, are (or should have been) aware that some contributors will stop contributing just because of that, while at the same time we ensure the project’s longevity by finally switching to more “modern” tools like Git.
[…] 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. […]
It ain’t “deprecated”, you know that, right? It’s just that some people like to force their world view, their ideology on others. Case in point “master” supposedly implied owning slaves. It’s rather fascinating that 99% of the English speaking world, i.e. first and second language English speakers mostly living outside of the US, don’t even understand the fuss about “master” yet we still have to put up with that shit, that language imperialism."master"master is deprecated nowadays, the new suggested name is "main".
It ain’t “deprecated”, you know that, right? It’s just that some people like to force their world view, their ideology on others. Case in point “master” supposedly implied owning slaves. It’s rather fascinating that 99% of the English speaking world, i.e. first and second language English speakers mostly living outside of the US, don’t even understand the fuss about “master” yet we still have to put up with that shit, that language imperialism."master"master is deprecated nowadays, the new suggested name is "main".
but also to reduce commands to single lines again, since git seems to often need multiple commands with options for simple operations.You can configure git aliases.
Helper apps to embed the checkout hash into apps also matter.
No worries, I returned the favour. Don't wrestle with pigs. You get dirty, and the pig likes it :-)Well, I might like it too. And I love bacon. :)
I wasn't there back then, so I can't say much about it. Speculative, maybe some people would have liked to stay on cvs, at least for some more time. They might not have spoken up, so how knows. But well speculation to be ignored....QuoteI guess you talk about the CVS to SVN?Yes. But that was different, because subversion had advantages for all user groups, not just a happy few that heavily use forward branches.
Also CVS development actively point to SVN as a successor, it was leaving a phased out (EOL) product. This is not the case with svn->GIT, and the tools are in many case a regression with git.
Well, that I can not take away. It will take it's time. And for some of us, be a bigger learning curve....QuoteSo did the change for fpc turn out to be good? Or would it be better, if fpc was still using cvs?
Definitely positive, but it still cost the project over an year, and while a bigger change in feature set, the amount of features used from the VCS was actually less. Little scripting and fixed procedures (e.g. for release and fixes branch maintenance).
So I expect it to be worse in this case, with smaller gains (which are also very unevenly distributed, and for some it might remain a netto minus).
Neither of those cases are now the case. The windows tooling is a step back, the commands are more complicated, the preparation less. And most importantly, SVN was not EOL.I am trying to help with getting from svn to git. But yes, time is quite short. And I have other stuff too.
more “modern” tools like GitThis is not helpful.
It’s just that some people like to force their world view, their ideology on others.It's a lot more complicated than this. But this is not for here to be discussed.
but also to reduce commands to single lines again, since git seems to often need multiple commands with options for simple operations.You can configure git aliases.
QuoteYes. But that was different, because subversion had advantages for all user groups, not just a happy few that heavily use forward branches.I wasn't there back then, so I can't say much about it. Speculative, maybe some people would have liked to stay on cvs, at least for some more time. They might not have spoken up, so how knows. But well speculation to be ignored....
Also CVS development actively point to SVN as a successor, it was leaving a phased out (EOL) product. This is not the case with svn->GIT, and the tools are in many case a regression with git.
Not sure about regressions, as I do not know what you refer too. Unless of course the need to adapt all scripts...
Well, that I can not take away. It will take it's time. And for some of us, be a bigger learning curve....
I can say, that I already benefited. I have for the past year (or year and a half) run my own 2-way mirror for Lazarus, and used it as if it was git. It has helped me a lot, and certainly saved me some time on my fpdebug work. (I.e. I used local commits as savepoints, and when I needed to recover from a mistake changing lots of sources, that saved me time / also it allowed me to compare before/after easily)
But I must also admit, that I spent a good 2 month of hard learning and falling (though I did not have anyone to ask, I had to google everything => so I hope that given that here we can support each other, learning time will be less)
Though, yeah, that does not help you.
EOL has worked well for me, using git.
Contrary to that I work all over the libraries, improving compatibility, small bugs, and doing the release branch work. I also work on multiple machines, which make local branches less useful, unless you create a complete shadow VCS.Well, I don't know your workflow.
EOL as in CVS being end-of-life.Ups...
I mean, “we”, collectively as the FPC project, are (or should have been) aware that some contributors will stop contributing just because of that, while at the same time we ensure the project’s longevity by finally switching to more “modern” tools like Git.
Case in point “master” supposedly implied owning slaves. It’s rather fascinating that 99% of the English speaking world, i.e. first and second language English speakers mostly living outside of the US, don’t even understand the fuss about “master” yet we still have to put up with that shit, that language imperialism.
I have then a git-server running, making that directory available as a server.
All my VM, and my laptop have that server as remote. (they have both, my local, and the true online remote)
Well, I don't know your workflow.
Some guide will be needed for smoother crossing from Mantis - explaining several best practice use cases with common category/label mapping. Otherwise everyone will have his own idea on how to achieve that...We are in the process, of importing *all* existing issues. During that process each team will decide what labels to use.
Thanks for that info. I have 2 new packages to add to FPC (can and bithelpers). Would it be better to provide patches now to Mantis or wait a little and do it in GitLab issues? I do not want to wait too much and miss FPC 3.4.0...Some guide will be needed for smoother crossing from Mantis - explaining several best practice use cases with common category/label mapping. Otherwise everyone will have his own idea on how to achieve that...We are in the process, of importing *all* existing issues. During that process each team will decide what labels to use.
I wonder what was the motivation for choosing gitlab over github? Self hosting possibility? Non M$? Code open sourced and available? Free storage size? Other?I have the same curiosity. But using git is definitely a great improvement!
Some guide will be needed for smoother crossing from Mantis - explaining several best practice use cases with common category/label mapping. Otherwise everyone will have his own idea on how to achieve that...
QuoteBut, 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.
< SARCASM MODE ON > :-[ :-[ :-[
If I remember well, many have complained that much more developers would contribute if GIT was the main version control system. Can't wait for that to happen...
< SARCASM MODE OFF > ;) ;) ;)
I wonder what was the motivation for choosing gitlab over github? Self hosting possibility? Non M$? Code open sourced and available? Free storage size? Other?
We'd probably roll our own instance of GitLab then. But the local commands wouldn't differ if the remote site is GitLab, GitHub or some plain Git repository.
The opposite (git support for svn (https://git-scm.com/docs/git-svn)) does exist, but isn't helpful in this context... I suspect the problem is mapping from more complex to less complex functionality. There is a kind of cheat sheet in the wiki that maps some common SVN operations to git equivalents (https://wiki.lazarus.freepascal.org/FPC_git#Common_SVN_operations_in_Git). Not the same as remapped commands, but a good cross-over guide.We'd probably roll our own instance of GitLab then. But the local commands wouldn't differ if the remote site is GitLab, GitHub or some plain Git repository.
Which I suppose raises the interesting question of whether anybody has already implemented a shim which implements Subversion checkout behaviour on top of Git.
MarkMLl
We'd probably roll our own instance of GitLab then. But the local commands wouldn't differ if the remote site is GitLab, GitHub or some plain Git repository.
Which I suppose raises the interesting question of whether anybody has already implemented a shim which implements Subversion checkout behaviour on top of Git.
Fpcupdeluxe extracts the SVN repo number from GIT, if it is stored.
Code: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/blob/master/gitclient.pas#L563
GitHub provides the ability to check out with SVN. So once we have a GitHub mirror of the GitLab repository that can be used.
There won't be any SVN revisions with the translated repositories and even if there were there won't be any new ones after the date of the switch.For sure. But it might perhaps be good to consider a GIT commit hook script to magically create a kind of revision number or sequence that is a bit more human readable than the normal GIT hashes. And can be used as a reference.
consider a GIT commit hook script to magically create a kind of revision number or sequence that is a bit more human readable than the normal GIT hashes. And can be used as a reference.+1
The hash is a hash of the data in the repo at that point in time. Its done to be a) unique and b) to guarantee the data. SVN's sequential number does a) but tells us nothing about the data. On the other hand, git, while good at b) cannot quite guarantee a). :D
There is a kind of cheat sheet in the wiki that maps some common SVN operations to git equivalents (https://wiki.lazarus.freepascal.org/FPC_git#Common_SVN_operations_in_Git).Actually in the spirit of GIT (more than one way for anything that may be done...), there are two: https://wiki.lazarus.freepascal.org/SVN_to_GIT_Cheatsheet
But it might perhaps be good to consider a GIT commit hook script to magically create a kind of revision number or sequence that is a bit more human readable than the normal GIT hashes. And can be used as a reference."git describe"
But tags need to be created yetYep. Looked into this, but its not trivial to be honest. However, tags seem to be the only way to get something that resembles sequential release info that is a bit human readable. I can fully imagine/understand that this will not be implemented, but its worth investigating.
I already did tests, should be easy.QuoteBut tags need to be created yetYep. Looked into this, but its not trivial to be honest. However, tags seem to be the only way to get something that resembles sequential release info that is a bit human readable. I can fully imagine/understand that this will not be implemented, but its worth investigating.
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.I don't see your problem. Instead of numbers you've hashes now but all of what you mentioned also works with hashes ;)
Contrary to that I work all over the libraries, improving compatibility, small bugs, and doing the release branch work. I also work on multiple machines, which make local branches less useful, unless you create a complete shadow VCS.For doing small changes (stuff that don't really need to be tested like typos or other trivial things) Gitlab has the big advantage of the Web IDE (actually you can even compile there if it's setup). It is also possible to browse the code from the web browser (desktop and mobile).
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.I don't see your problem. Instead of numbers you've hashes now but all of what you mentioned also works with hashes ;)
- It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.
- Providing a editorconfig (https://editorconfig.org/) file would help to have less problems with indentation and so on of people contributing code
- The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included
- The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included
We have excluded those files and directories by experience. It's not enough to exclude selected files, because what is placed in e.g. the units directory might differ: If I should test something that outputs an additional file during compilation I don't want the whole bunch of units directories to pop up in git status.
I did and I explained to you that it does but just in the 'git' way where numbers == hashes. You can't expect to get the same output with a complete different principle. Don't try to see everything through a 'svn' view.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.I don't see your problem. Instead of numbers you've hashes now but all of what you mentioned also works with hashes ;)
Read the full thread before commenting. Sequential numbering doesn't work.
Not sure if you understood what I meant. If you go to the Milestones (https://gitlab.com/freepascal.org/fpc/testconversion2/-/milestones), you'll notice that no issues are assigned to them. Instead every issue has a label that indicates the version it belongs to. That's not really following the general 'Gitlab principle'.
- It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.
The versions are the milestones, we don't consider anything else.
Didn't said that but some units e.g. might use tab size of 2 and others using 4. This could be individually configured with the EditorConfig.
- Providing a editorconfig (https://editorconfig.org/) file would help to have less problems with indentation and so on of people contributing code
Different parts of the project use different coding styles (e.g. compiler vs. RTL vs. packages). And this will not change.
If you scroll through the .gitignore file you should notice that it always list the file extensions .exe, .o and .ppu which is kinda nonsense as you could use wildcards which will block them as well. If you want to commit and track single files of these types, just add this explicitly to the gitignore.
- The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included
We have excluded those files and directories by experience. It's not enough to exclude selected files, because what is placed in e.g. the units directory might differ: If I should test something that outputs an additional file during compilation I don't want the whole bunch of units directories to pop up in git status.
For doing small changes (stuff that don't really need to be tested like typos or other trivial things) Gitlab has the big advantage of the Web IDE (actually you can even compile there if it's setup). It is also possible to browse the code from the web browser (desktop and mobile).
And for the multiple machines, why don't you fork the project and push your changes to your user repository? Then you have your 'local' remote branch that can easily be shared (you only need internet access on all machines).
- It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.
Lets just establish a bit common ground here.+1
To use git, one has to break with old habits. And "old habits die hard".
Lets just establish a bit common ground here.+1
To use git, one has to break with old habits. And "old habits die hard".
Not sure if you understood what I meant. If you go to the Milestones (https://gitlab.com/freepascal.org/fpc/testconversion2/-/milestones), you'll notice that no issues are assigned to them. Instead every issue has a label that indicates the version it belongs to. That's not really following the general 'Gitlab principle'.
- It might be better to assign the created issues to the appropriate milestone instead of adding labels like Version 3.2.0. I mean you've the milestones with the versions but don't assign any issues. The label is no longer required.
The versions are the milestones, we don't consider anything else.
Didn't said that but some units e.g. might use tab size of 2 and others using 4. This could be individually configured with the EditorConfig.
- Providing a editorconfig (https://editorconfig.org/) file would help to have less problems with indentation and so on of people contributing code
Different parts of the project use different coding styles (e.g. compiler vs. RTL vs. packages). And this will not change.
If you scroll through the .gitignore file you should notice that it always list the file extensions .exe, .o and .ppu which is kinda nonsense as you could use wildcards which will block them as well. If you want to commit and track single files of these types, just add this explicitly to the gitignore.
- The .gitignore file could be shrinked by using wildcards as this would simplify much of it: e.g. with *.exe *.o *.ppu all (sub)directories are automatically included
We have excluded those files and directories by experience. It's not enough to exclude selected files, because what is placed in e.g. the units directory might differ: If I should test something that outputs an additional file during compilation I don't want the whole bunch of units directories to pop up in git status.
Does this mean that it will no longer be possible to refer to a particular stage of trunk development as "revision such-and-such", and to step forwards and backwards from that point using a contiguous sequence of revision numbers?Mainly, yes.
The exact details on the below are still being evaluated. Outcome not yet known....
will return output like this
This are 3 fields
* The name of a label
* The amount of commits from that label (everything git log would see for that range)
* The short hash-id (for access to the exact commit)
You may notice that the example in the fixes branch is based on 2.0.8, even though I can tell you the commit for this is past 2.0.12.
The reason is that 2.0.12 "branched" from the fixes branch. Therefore the 2.0.12 label was not found.
But the general idea, of having some sort of "sortable" reference is still valid.
However those numbers are not 100% unique.
Do you envisage some way of doing a binary chop based on that reference?
Does this mean that it will no longer be possible to refer to a particular stage of trunk development as "revision such-and-such", and to step forwards and backwards from that point using a contiguous sequence of revision numbers?We could use Firebird's build number schema via CI/CD [Continuous Integration and Continuous Delivery]:
MarkMLl
@Martin_fr Suggestion: Removing "-IDE" from Lazarus group name.I've changed the URL.
What URL?The group name itself can afaik not be changed (other than starting from scratch / no thanks). But that is a display name. So it should not be a problem. (if you copy and paste it as "lazarus" people will still know)
I meant Gitlab project name for Lazarus.
It was not updated the previous check but now it is Lazarus.
Thank you for the update!
Project names will be FPC and Lazarus like the group names?
It is a bad news for who live underground world, like me.Meaning?
ah, gitlab blocking some countries, Syria one of ot because it is based on google services.
https://twitter.com/compumaster/status/1029164513856110593
https://about.gitlab.com/blog/2018/07/19/gcp-move-update/?utm_medium=social&utm_source=twitter
ah, gitlab blocking some countries, Syria one of ot because it is based on google services.
https://twitter.com/compumaster/status/1029164513856110593
https://about.gitlab.com/blog/2018/07/19/gcp-move-update/?utm_medium=social&utm_source=twitter
Yes and no, originally the plan was a own hosted gitlab instance, now the plan is move to the gitlab cloud.
And that's why I am in favour of self-hosting.
I am aware of a claim that somebody was treated very harshly after sending money to the family of his web developer who was killed by USA-allied fire in the Balkans.Politics... the bug that cannot be debugged.
git pull http://server/repro FOO for me as developer I can access gitlab using vpn (until now),
the most important is download binaries, if you can put mirror on github, or any site that not censoring it, it is good idea, it is for normal developers in sanction countries.
The date for the final conversion has been established as the weekend of 17/18 july.
And that's why I am in favour of self-hosting.
I echo that sentiment.
I asked the same about Lazarus but since they are different projects, can anyone tell us what will happen with the repo at:
https://svn.freepascal.org/svn/fpc/
???
I would suggest not to touch your current fpcupdeluxe install.
Was it really necessary to take down the svn server before everything is in place on gitlab?
I would suggest not to touch your current fpcupdeluxe install.
Fortunately I have btrfs and snapshots, otherwise I would not have a working Lazarus installation anymore now :-/.
It would be nice to know the reasons for moving from SVN to GitLab. At least for the sake of simple interest and information for users.
git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git mylazarusdirand from then on,git pullfrom "mylazarusdir"All necessary information to connect to gitlab will be collected in the FPC &
Lazarus Wiki. Several pages have already been set up:
https://wiki.freepascal.org/FPC_git
https://wiki.freepascal.org/FPC_git_concepts
https://wiki.freepascal.org/SVN_to_GIT_Cheatsheet
These pages will be updated with the correct URLS when the final conversion happens. The FPC & Lazarus websites will also be adapted with new instructions.
Very unprofessional.
hi there. i've also noticed there are teething problems with the snv to git convertion. i have found that lazarus gitlab is setup without problems, but when i do a search for FPC, it doesn't exist...is there a reason for that
hi there. i've also noticed there are teething problems with the snv to git convertion. i have found that lazarus gitlab is setup without problems, but when i do a search for FPC, it doesn't exist...is there a reason for thatAs I said before...
Why do you have to switch from SVN to GIT now? SVN is highly professional and stable. Why these changes all the time? When a server is down, I buy a new one and copy everything. Finished.Has been answered at least 3 times.
Why do you have to switch from SVN to GIT now? SVN is highly professional and stable. Why these changes all the time? When a server is down, I buy a new one and copy everything. Finished.
...And if you don't want to use even that minimal git command, you can pull down a full zip or gz file in less time than the source forge ads ran for when grabbing a binary.
For non-developers who use trunk in stead of svn co/svn up, you now have git clone/git pull to obtain current sources.
Making diff's/patches is equally simple.
....
...And if you don't want to use even that minimal git command, you can pull down a full zip or gz file in less time than the source forge ads ran for when grabbing a binary.
For non-developers who use trunk in stead of svn co/svn up, you now have git clone/git pull to obtain current sources.
Making diff's/patches is equally simple.
....
Davo
Maybe a screenshot could be added in the wiki.Depends on which wiki site.
Unless a page is explicitly about download zip/tar, it should probably first focus on "git clone" then on "packed download".
I am not saying it shouldn't be there.Unless a page is explicitly about download zip/tar, it should probably first focus on "git clone" then on "packed download".
Of course for lazarus-developers "git clone" is needed because it will download also all the .git data.
But for Lazarus-users who dont need all the .git data, download zip/tar (that does not include all .git data) is a good/lighter solution, with only one click.
It depends on what the page targets.
Also keep in mind, that anyone who does not only download zips for releases (which are avail on sourceforge too), will be better off with a git clone.
Once you got the clone, you only have to download the differences to what you already have.
The Lazarus fixes zip is currently at 50MB. A full clone iirc at 170MB. Less than 4 times the amount. Once you download your 4th zip....
And if needs must, but I would not recommend it to a git newcomer, there is "--depth".
And congratulation for your work Martin, the conversion of Mantis-bugtraker into Lazarus-GitLab-issues is clear, complete and respectful for patchers.
And congratulation for your work Martin, the conversion of Mantis-bugtraker into Lazarus-GitLab-issues is clear, complete and respectful for patchers.
The Mantis to GitLab was for the most part Michael. I did help only a little.
04/08/2021 15:55
[T]here is an unforeseen delay in the conversion of the FPC svn -> git repository. I think we're meanwhile at attempt 7...
The conversion takes a lot of time (>48 hours in total). As long as the conversion is not finished, the repository is marked private, and you will get a 404; only team members have access at this point.
Michael Van Canneyt
Thanks for the update! ;)Quote04/08/2021 15:55
[T]here is an unforeseen delay in the conversion of the FPC svn -> git repository. I think we're meanwhile at attempt 7...
The conversion takes a lot of time (>48 hours in total). As long as the conversion is not finished, the repository is marked private, and you will get a 404; only team members have access at this point.
Michael Van Canneyt
Michael Van Canneyt via fpc-pascal wrote on 08/08/2021 19:13
Hello,
After several technical issues (8 tries were needed to convert the FPC
sources to git), the move from svn/mantis to gitlab has been completed.
The FPC sources are now available at
https://gitlab.com/freepascal.org/fpc/source
All FPC git repositories are available at:
https://gitlab.com/freepascal.org/fpc
This is also where bugs can be reported from now on:
All Mantis issues have been converted to Gitlab issues.
Depending on where you report an issue, the Gitlab system will ask you to
select a project under which to report a bug.
Note that e.g. documentation bugs should be reported in the documentation
repository:
https://gitlab.com/freepascal.org/fpc/documentation
etc.
A redirect has been put in place for the old bug system, if possible the
system will redirect you to the correct issue in Gitlab.
A similar redirect will be put in place for the viewvc repository view tool.
The "development" page has been updated with the necessary instructions to
connect with Git:
https://www.freepascal.org/develop.html
More information about git has been placed in the WIKI:
https://wiki.freepascal.org/FPC_git
The lazarus team also placed a version at
https://wiki.freepascal.org/SVN_to_GIT_Cheatsheet
If you see places where we overlooked updating the SVN to git or mantis to
gitlab information, please let us know...
Michael.
What is the recommended way to update my Lazarus installation on Mac?If you don't put any files you never commit, simply delete the old folder then:
In past I would navigate to lazarus folder and use svn up
I need to update sources I think to get access to recent updates for WKWebkit
$ git clone git@gitlab.com:freepascal.org/lazarus/lazarus.git
Don't forget to have a gitlab account and generate SSH keys on your machine if you haven't, then copy the public key by pressing "Add key" on this page (https://gitlab.com/-/profile/keys). Alternatively, you can clone with https but I strongly recommend using SSH keys for convenience.
Don't forget to have a gitlab account and generate SSH keys on your machine if you haven't, then copy the public key by
In past I would navigate to lazarus folder and use svn uphttps://wiki.lazarus.freepascal.org/FAQ_SVN_to_GIT
That's strange... I don't remember having to sign up like that when using Subversion :-/You don't, if you only download. No username, no password needed.
You don't, if you only download. No username, no password needed.I clearly remember my git clone was rejected before registering. Perhaps this only works with HTTPS?
The url you mentioned, looks like an url for an ssh client. And ssh requires you to auth.You don't, if you only download. No username, no password needed.I clearly remember my git clone was rejected before registering. Perhaps this only works with HTTPS?
What is the recommended way to update my Lazarus installation on Mac?
In past I would navigate to lazarus folder and use svn up
+1It depends on what the page targets.Imho a Lazarus newcomer that dont know SVN nor Git will be much more comfortable with Git.
Also keep in mind, that anyone who does not only download zips for releases (which are avail on sourceforge too), will be better off with a git clone.
Once you got the clone, you only have to download the differences to what you already have.
The Lazarus fixes zip is currently at 50MB. A full clone iirc at 170MB. Less than 4 times the amount. Once you download your 4th zip....
And if needs must, but I would not recommend it to a git newcomer, there is "--depth".
It is a courageous an excellent decision to move to Git.
And congratulation for your work Martin, the conversion of Mantis-bugtraker into Lazarus-GitLab-issues is clear, complete and respectful for patchers.
Fre;D
Oh!!? Thanks @trev: finally, i'll continue for a while, testing with your SVN checkout commands.
I suggest to use the svn mirror github *only* if there is no working git client for the system one is using. Even for "Read only" users: git is normally faster and a git working copy takes less space.
I suggest to use the svn mirror github *only* if there is no working git client for the system one is using. Even for "Read only" users: git is normally faster and a git working copy takes less space.
Maybe on *nix, but on Windows, git is much slower IMHO. Using one repo for both branches is pointless, since I also have multiple lazaruses pointing towards them that use them for debugging etc. (quite often: fixes for work, and trunk to quickly check bugreports).
The SVN checkout was 300MB, a git one is 500MB. Yes, in theory that contains all branches, but IMHO that is of limited use for the source repo.
Some of the speed differences might be cloud vs own server though, not git vs svn
I suggest to use the svn mirror github *only* if there is no working git client for the system one is using. Even for "Read only" users: git is normally faster and a git working copy takes less space.
Maybe on *nix, but on Windows, git is much slower IMHO.
Using one repo for both branches is pointless, since I also have multiple lazaruses pointing towards them that use them for debugging etc. (quite often: fixes for work, and trunk to quickly check bugreports).
Martin was faster ::)
BUGS
Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.
Martin was faster ::)
I already knew, but the docs say:QuoteBUGS
Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.
Still I'll experiment with it on secondary machine.
I suggest to use the svn mirror github *only* if there is no working git client for the system one is using. Even for "Read only" users: git is normally faster and a git working copy takes less space.
Maybe on *nix, but on Windows, git is much slower IMHO.
Creating new issues is disabled. A few days ago it was enabled, then suddenly it was disabled, then yesterday enabled again for a short time and now it is disabled again. This also affects the Lazarus project.
See screensot.
Wow, this is really bad UI. The issue list should be empty if I am in an area where there can't be any issues. And if it instead shows an aggregated list of all sub-project issues there should (for reasons of symmetry) also be a new-issue-button that allows me to choose for which sub-project I want to create a new issue. Or at least a greyed out new-issue button with a hint that no project is currently selected.
Wow, this is really bad UI. The issue list should be empty if I am in an area where there can't be any issues. And if it instead shows an aggregated list of all sub-project issues there should (for reasons of symmetry) also be a new-issue-button that allows me to choose for which sub-project I want to create a new issue. Or at least a greyed out new-issue button with a hint that no project is currently selected.
Well, you'll have to complain to the GitLab developers about that.
https://gitlab.com/freepascal.org/fpc/documentation says "See https://docs.freepascal.org/ for the rendered online version of the documentation", but the link doesn't load for me...? In fact https://freepascal.org / https://www.freepascal.org don't load either.
Is there any way to do an SVN checkout to the Gitlab freepascal/lazarus repos ??SVN checkout from the Gitlab repository? No, but git clone is super easy.
Helloooooooo,
Tel me gays ! Is there any way to do an SVN checkout to the Gitlab freepascal/lazarus repos ??
Helloooooooo,
Tel me gays ! Is there any way to do an SVN checkout to the Gitlab freepascal/lazarus repos ??
We have 2 "svn 2 git translations" on our own wiki:Helloooooooo,
Tel me gays ! Is there any way to do an SVN checkout to the Gitlab freepascal/lazarus repos ??
https://stackoverflow.com/questions/18900774/equivalent-of-svn-checkout-for-git