...

Yes indeed, one issue is:

your code is
{
{
{
way
{
over here

Compare that to oberon or even Plain C where your code:

someproc {
is here
}

Not here:

{
{

{
system.print()

Same issue with C#

Not an issue with: golang, fpc, delphi, oberon, C, or even in some cases ruby

The amount of nesting and indented procedures inside classes in Java is horrible, IMO.
Just to get a program started you are

way over here
by morning
and worse
by night

What about Rust or plain C? Or Digital Mars D?

Biggest problem with C is all the manual memory management, like strings, for example, that IMO morons waste hours of time on and create buggy code, all needlessly and unnecessarily.

Or instead of using rust/c/java, simply fix FPC, which is a good solution IMO, as not only does it speed up some boring game test case, but fixes other things that people didn't know about which were slowing down their app.

I don't see how ZenGL and Andorra3D have been able to succeed as game engines with all these performance issues in the RTL/compiler? Did they work around them and swap in their own faster code, instead of reporting the bug/issue to the fpc bug reporting?

Indeed it is not exactly a bug but could just be correct code that is slow.

The amount of nesting and indented procedures inside classes in Java is horrible, IMO.

It's not a Java language issue, but the indent preference of the developer. Many Java IDE's support multiple coding styles and does auto-formatting as you type or save. Some coding styles are better than others, and all of them are configurable.

Regards,
Graeme

What about Rust or plain C? Or Digital Mars D?

I hate C with a passion. I'll never code in that ever again.

I also have no interest in learning "the new language flavour of the month" - which will be obsolete in a year or two. Object Pascal is already pretty irrelevant when it comes to looking for jobs - I'm a freelancer / contract programmer. Though it has served me very well since TP 5.5 and then again from Delphi 4 onwards.

I now go where the work is (as well as the money - but enjoyment of work is still a higher priority for me).

Or instead of using rust/c/java, simply fix FPC, which is a good solution IMO

I don't know compiler design or how it works internally. So contributing in that area is out of my scope.

I don't see how ZenGL and Andorra3D have been able to succeed as game engines

I can't speak for those, but have used OpenGL with FPC for a few months. I'm definitely no OpenGL expert, but I did manage to off-loaded a lot of work via shaders to the GPU. So that frees up a lot of what FPC has to do with the general game "ticks".

Indeed it is not exactly a bug but could just be correct code that is slow.

Many seem to miss the whole point of what I was trying to say. Other compilers did a much better job than what FPC could manage - using the exact same code (just the language syntax that differed). I didn't need to change anything for GCC or Java, and I didn't have to implement all kinds of work-arounds.

Either way, I've run out of energy discussing this. I profile my code one more time and try the suggestions in Jonas. Simply because I'm curious. But other than that, my project has already moved forward using Java.

Regards,
Graeme

It was actually a case, not typical at all for game development. It was software rendering and game engines almost always use hardware rendering, even for 2D games. And a huge part of the performance difference was caused by the highly specific fact that floating point to integer conversion is slow on the x87 FPU and SSE3 improves this a lot. If it was regular floating point, without so many integer conversions, SSE3 wouldn't matter, and I'm guessing that SSE2 wouldn't make a lot of difference. Disclaimer: I have not tested this. :)

And yes, Florian, Jonas and Sven did a few small optimizations, which is a good thing, but they are nowhere near as impactful in general use cases as people think ( which is related to the fact that the FPC optimization performance is not as bad as this particular test was making it out to be :) )

Nikolay

What happens if you use the SVN bridge that allows you to run svn commands to a git server?

Maybe your wording is confusing, or SVN has abilities I didn't know of. I know Git can manage SVN repositories, but I didn't know it was possible other way round (I doubt it is possible).

I often use Git to manage SubVersion repositories I don’t have control over. For everything else I’ve moved over to Git years ago.

Local working copy issues Florian described would be an issue with this bridge, or not an issue?

As with any new applications or technologies, there is always some learning curve (big or small). There are tons of bad habits ingrained in SVN users. Those do not translate well to Git (thank goodness). Git works fundamentally different to SVN (for the better). So you need a change in mindset - some refuse, hence they struggle with Git. And then wrongly blame Git for it. I fear this is most likely what happened with Florian.

There are also 100’s of different work-flows for when you work with Git repositories. I’ve introduced Git into many companies. In every case I look at how they work, suggest an already existing work-flow as a starting point (*), and then tweak it to their needs. In they end they get exactly what they want, and without fail all of my customers said they should have made the switch years ago.

* - My all time favourite git work-flow is:
http://nvie.com/posts/a-successful-git-branching-model/

It works very will for small and large teams. Supports big or small features. Allows for long-term support releases as well as quick bug-fix releases.

Regards,
Graeme

Nikolay Nikolov wrote

> Isn't java just a wrapper around C? No. Java compilers generate code for a virtual machine, called JVM (Java Virtual Machine). They do not generate code for x86 CPUs or any other ...snip...

Very nice explanation and detailed information.

x87 FPU instructions. Sounds so great, you're going to ask if there are any disadvantages to this approach? And, of course, there are - since the program is essentially recompiled every time the user runs it, starting Java programs take a long time.

Technically correct, but you make it sound much worse than it really is. Here Eclipse IDE starts up just as fast as Lazarus IDE. And Eclipse is easily 10x or more bigger than Lazarus (when it comes to features). So JIT does a pretty damn good job if you ask me.

Also JIT has improved tremendously over the last few years. In speed, performance and optimisations. I have read somewhere that now it does a [quick] compile to get your application up and running faster, then after your app is running it can recompile some classes with even more optimisations, and runtime reload those classes used by your application. All done auto-magically in the background. ;-)

be a lot slower than a FPC program. I know comparing different IDEs is a little apples-to-oranges comparison (because they may have different features and vastly different implementation details), but compare the speed of e.g. Lazarus to any IDE, written in Java, even the fastest one. :)

Lets just look at the two most popular Java IDEs - Eclipse and Intellij IDEA. When they are running I don't experience any speed difference comparing them to some native non-Java application of similar size.

It is also worth noting that both Eclipse and Intellij IDEA does a ton more than Lazarus IDE. They both do deep code-analysis while you are coding, making suggestions on how you can improve your code, can apply those improvements with a single click or keyboard shortcut, have extremely impressive refactoring functionality that makes Lazarus look like Notepad. And the list goes on and on.

Lazarus is good, but it doesn't hold a candle against what Eclipse or Entellij IDEA can [and does] do. Yes, yes, I know they have 100's or 1000's more developers too, and corporate backing. So making a comparison between those IDE's and Lazarus is rather insane.

Always measure and try to understand why something is slow. In 99% of the cases it's not what people initially think.

Indeed. I've learned a lot in the recent discussions, and I'm glad to see the FPC team seem to be making some effort in improving the compiler optimisation, instead of simply dismissing my work and comments.

Regards,
Graeme

Graeme Geldenhuys wrote

On 2017-05-22 23:11, wrote:

Hi Graeme,

.
.

.
.

There are also 100’s of different work-flows for when you work with Git repositories. I’ve introduced Git into many companies. In every case I

.
.

I won't comment your generic statements praising one tool and condemning the other, but let me remind you, that it isn't just about Florian. During the previous discussions on this evergreen topic, Florian, Marco, Jonas (if I remember correctly) and others raised quite a few specific questions on how to accomplish particular tasks commonly used in the FPC project. I may have missed something, but I haven't noticed a particular proposal from you or anyone else describing in detail how to cover those needs (possibly a proposal altering the current practice, but still allowing to achieve the original goals). This was how we performed the CVS to SVN transition in the past.

People interested in changing the tools should be those coming with a particular workable proposal on how to use the tool. You should not expect that those happily using another tool _and_ performing many more interactions with the current tool than you (without major issues) would be keen to invest their time in analyzing all possible workflows, etc., of a new tool just to find out, if they could achieve the same outcomes with another tool as well as with the current one. Also, note that while many things may work well in theory, solutions requiring users to be perfect (e.g. having high level of discipline to perform certain things in certain way resulting in the wanted outcomes) will rarely work so well in reality...

Tomas

To be honest, I can't actually remember seeing any such proposal (asking for advice or help) in the FPC-Users mailing list. Maybe it was in a list I'm not subscribed in? Otherwise, I would have happily given my advice.

I also don't expect somebody with no or very little Git experience to give any good advice on such a matter either. I believe most of the FPC team don't have any or very little Git experience.

I can add that I have been working closely with Michael van Canneyt for the past two years. In the last few months I have introduced Git in his workplace too, and his knowledge of Git has improved a lot. So maybe in the next round of proposals, Michael will be able to offer some more advice too.

So again, if the FPC team ever wants to consider Git, feel free to contact me so we can bounce around some ideas.

Regards,
Graeme

In our previous episode, Graeme Geldenhuys said:

That is your very colored view about it, that automatically declares non-gits stupid.

However in the last discussion we showed you various faqs (like from LLVM and FreeBSD) that mirrored the FPC core teams.

emacs! vi!

Let's call the whole thing off and use EDLIN.

Marco van de Voort wrote

In our previous episode, Graeme Geldenhuys said:> As with any new applications or technologies, there is always some > learning curve (big or small). There are tons of bad habits ingrained in > SVN users. Those do not translate well to Git (thank goodness). Git > works fundamentally different to SVN (for the better). So you need a > change in mindset - some refuse, hence they struggle with Git. And then > wrongly blame Git for it. I fear this is most likely what happened with > Florian. That is your very colored view about it, that automatically declaresnon-gits stupid. However in the last discussion we showed you various faqs (like from LLVMand FreeBSD) that mirrored the FPC core teams.

One question if I may. Subversion has revision numbers like 12345, and it's comparatively easy to query that and build it into a piece of software's version information. It's also trivial for a developer to look at the revision that he's currently working with, to say whether it's older or newer than revision 12345, and to get a log of what the relative changes were by /only/ knowing the revision number.

Now I don't deny for a moment that Git has its advantages for distributed working. But am I correct in my understanding that it has nothing that maps directly onto the monotonic revision list of traditional VCSs including Subversion?

In our previous episode, Mark Morgan Lloyd said:

Now I don't deny for a moment that Git has its advantages for distributed working. But am I correct in my understanding that it has nothing that maps directly onto the monotonic revision list of traditional VCSs including Subversion?

Nope. There is only some hash, and various hacks to emulate with post commit hooks, which is not at all the same in behaviour.

some info is at
http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git

merging, external repos were some of the other issues. (Potentially) solved issues since the previous discussion were repo dictated configuration (for linefeeds), and the ability to avoid certain branches to have multiple ends (thus leaving the next committer with the unenviable choice to wait or potentially make the situation even more complex).

All from memory of ourse.

Mark Morgan Lloyd wrote

One question if I may. Subversion has revision numbers like 12345, and it's comparatively easy to query that and build it into a piece of software's version information.

And the same is true for Git. By design, distributed version control systems (any of them, not just Git), can't rely on a sequential number. The word "distributed" should say it all. True parallel development; no single "server" instance etc.

Saying that, git includes a command 'git describe' which does what you need. I find its result also way more useful and informative that a single sequential revision number - which only has a mean to a developer. Lets use an example:

[reportdesigner (reportdesigner)]$ git describe
v1.4.1-787-g45f932c1

What does that output tell me:
* Whatever code I'm working on is follow on from the "v1.4.1" release.
* This line of [development] history has seen "787" commits since the v1.4.1 release.
* The "g" prefix indications that the Git revision control system was used.
* The "45f932c1" is the SHA1 value of the last commit, that uniquely identifies where we are in the whole history of the project. Irrespective of having 1 or a 1000 branches.

Now as with anything Git, everything is configurable. So the git-describe commands has many optional parameters too. So you can change the output to suite your project's needs. Things like should Tag names be used in the git-describe output, or only Annotated Tags, or only Branch names. Do we want the commit count, do we want the "g" prefix, how long SHA1 value do we want etc etc.

Many applications incorporate such output in there version information. See attached screenshot of one such example. I've seen plenty of others too.

What does a SubVersion revision r20453 tell you?

* Which branch are you on?
* Which release is this work based on?
* Is it a "hotfix" or new feature.
* Is it maybe a tag? Though Subversion doesn't really have a concept of tags, as they are just branches in a bad disguise.

No, it only tells you that you are using commit number 20453.

So now the next thing you are probably going to tell me is that yeah but I can use the revision number in Windows's version numbering as a Revision or Build value. Yes and No. Only if your repository has less than 65535 commits - the maximum a WORD type supports. So what happens if you have more commits that that? Many large projects do.

It's also trivial for a developer to look at the revision that he's currently working with, to say whether it's older or newer than revision 12345,

As I just explained. The git-describe output tells you that and more.

and to get a log of what the relative changes were by /only/ knowing the revision number.

Nothing new, Git does that too. Git (no surprise) even goes further and also tells you the Parent(s) commit that got you there, the Child/Children commits following on, what branch it is on and what Tags this commit follows.

Regards,
Graeme

Marco van de Voort wrote

some info is at http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git merging, external repos were some of the other issues.

Good Lord, who wrote that, and when? Clearly someone with a serious lack of Git knowlegde - just the thing I described 2 replies ago.

"
However, we propose to mandate making merge commits illegal in our canonical Git repository.
"

WTF? Branching and Merging are two key feature of Git. So if the don't want merging (or only allow fast-forward merges), I guess they want to Rebase everything everybody contributes - yeah the lovely linear history of SubVersion.... because they don't know better.

Regards,
Graeme

Or maybe they haven't forgotten how nice and simple svn is.

Git just doesn't do KISS.

---
(I use both git and svn, and both have things that I personally miss on the other)

But at least this thread is highly amusing, so thanks for that.... ;)

Martin Frb wrote

Git just doesn't do KISS.

Git is as complicated as you want it to be.

If you want to use it like SVN, then go right ahead. You will miss out a lot though. I always recommend newcomers to start out with the basic 4-5 commands (same as SVN). Then as your confidence grows, introduce new Git functionality.

And contrary to what many may think, it is pretty near impossible to f*ck your repository up so that things are unrecoverable. As long as something was committed, that something can be recovered, or commands can be undone (yes, even deleted branches). Try that with SubVersion!

Regards,
Graeme

Hi,

Martin Frb wrote

Or maybe they haven't forgotten how nice and simple svn is.

Erm, I really don't want to be involved in the usual religious war, personally I use exclusively Git these days (for personal stuff), but I don't mind SVN, CVS, or whatever a project uses I'm working on. But.

Git just doesn't do KISS.

You need an SVN server to start working with SVN. With Git, you go to a directory, do "git init" and start committing. Everything is local. Not sure how that's not KISS. (You can add a remote later, and then push to it, with the full history intact. This remote can even be an SVN repo.)

Also, you retain the full commit history locally, so you don't need access to the server to get logs, get diffs, etc. Ever tried to work on a project hosted in a centralized VCS, while on a 10 hour plane flight with no internet? Or travelling in another country, where your roaming doesn't work?

Also, ever tried to do partial commits in SVN? (Not committing all the changes in a single file.) (git add --patch)

Also, ever tried to just make clean build of trunk quickly in SVN then reapply your local, not committed changes? Or try your local changes on another branch without committing them? (git stash)

Agreed, Git adds some complexity due to it's distributed nature, and because you don't have nice monotonously increasing revision numbers. But seriously, it makes a billion things much simpler and easier in exchange, especially if one learns to exploit its features for the everyday workflow. It's a tool to manage your source code, even *before* you commit your changes. While SVN is still seen and used by many people as some kind of "incremental source backup". And indeed, it's barely useable for anything more, if we're honest.

But as I said, I'm fine with $whatever VCS, I'm not forcing anyone. Heck I still see great software developed in CVS or even without any VCS (that's quite extreme tho', admitted), because no tool can replace a great developer. But great developers know how to make their own life easier. ;)

My 2 cents,

Every tried:

C:\temp>svnadmin create repos

C:\temp>svn checkout file:///c:/temp/repos wc
Checked out revision 0.

?

Also, ever tried to do partial commits in SVN? (Not committing all the changes in a single file.) (git add --patch)

I do it daily with FPC (using TortoiseSVN though).

Karoly Balogh wrote

Also, ever tried to do partial commits in SVN? (Not committing all the changes in a single file.) (git add --patch)

To be fair: at least on Windows that is very easy with the help of TortoiseSVN :)

Regards,
Sven

First problem: quote from core:

But actually, as long as llvm and gcc still use svn, svn should fulfill our needs as well :)

In our previous episode, Karoly Balogh (Charlie/SGR) said:

The previous discussions were about team use of GIT, to be specific, FPC core repo.

The problem is that if problems get practical the advocatists suddenly step back and aren't really able to do more than regurgitate either the standard beginner "wisdoms" or "you shouldn't want this" or "this is the new improved ways" or similar platitudes.

To get get back on track, I'll restate the question I posed in the last message unambigously:

how to avoid that a push of member X doesn't leave a branch in an undesirable state that leaves member Y three choices:

1. push anyway and make the mess worse
2. hold the commit/push
3. clean the mess himself.

In your own repository that is no problem, and even in companies this only takes only a few LART/cluebat applications to fix. However in distributed teams this is a pain.

Hi,

No, nice to know this works, thanks. However, then if you try to publish this repo outside of your computer, it gets a bit hairy. (Nothing unsolvable, but nothing which I would describe as KISS anyway.)

> Also, ever tried to do partial commits in SVN? (Not committing all the > changes in a single file.) (git add --patch) I do it daily with FPC (using TortoiseSVN though).

Yes, TortoiseSVN makes this bearable, this was more or less the only reason I used a Windows 7 box + Linux VirtualBox combo for development at the last company which used SVN. :) But it's not the feature of SVN as such.

Charlie

Hi,

How to avoid that member X with commit write access doesn't leave a branch in SVN in an undesirable state? :) You have to trust people, and choose who you give write access to a given branch/repository, really. This didn't really change and not an argument against git.

And well, in Git you don't push, but people who want to contribute, have a pull request. Then you can review that, and either apply to your tree or reject it. It's important to understand that in git all repositories are equal, and that I have a "make-amiga-great-again" branch, doesn't mean that you should have it, I could still send a pull request against your master branch, or whatever branch. All pull requests are just a set of changes, really.

1. push anyway and make the mess worse 2. hold the commit/push 3. clean the mess himself.

Well, ideally in distributed teams, people don't push, but have a pull request. Basically as crazy as it sounds, everyone forks the project all the time, but then you have a set of tools to reintegrate all those forks easily. It's the responsibility of the maintainer of a given branch to accept that pull request or not, or request further changes before its accepted.

In your own repository that is no problem, and even in companies this only takes only a few LART/cluebat applications to fix. However in distributed teams this is a pain.

No, it isn't. This is the primary problem git solves, actually, by making it possible for everyone having their own sandbox to play with, and you have a review filter before accepting changes. You can even sign off changes by a maintainer, who reviews the code. All those messy branches remain local if they're not approved, on the person's computer who messed it up, they don't have to go global/upstream...

And talking about myself - as much as I enjoy just committing my crap to trunk, I sometimes would really prefer review. Not because I'm not a senior engineer, but especially because of that... Now if I don't want to do a branch in SVN which are huge and expensive (Git branches are cheap and small), I either have to commit it first anyway to trunk, then ask for a review, or send a patch for review first in e-mail, which is quite cumbersome. Plus there's absolutely no warranty, that I later commit the same patch which was reviewed.

At work, I don't even push against master, but I do a pull request against my own repository, and ask one of my senior colleagues to review... I don't know about you, but to me this sounds a lot more like teamwork, than going around beating up people "for wrongdoing" with a cluestick.

Of course in the end it's just like crypto - you need to have a chain of trust from the top, a group of trustees who will do the actual merging of the pull requests, reviews and then push it upstream/mainline/trunk. If one of these maintainers do a bad job, then you need to sort out that problem, but that doesn't mean the whole system is broken. It's similar to giving commit access to a developer who doesn't deserve it in SVN, really.

Now, how the actual process would look with the FPC team, that's hard to define at this point. But the tools are there for it.

Was this a proper answer, or I was beating around the bush in your views? :)

Grmbhl,

Karoly Balogh wrote

Now, how the actual process would look with the FPC team, that's hard to define at this point. But the tools are there for it.

Exactly what I was getting at.

Was this a proper answer, or I was beating around the bush in your views? :)

Finally somebody that understands distributed version control, and how Git could be used. You gave a very good answer indeed. Too many people (and companies) are so stead fast in the ways of a client/server version control system - like SubVersion. They then wrongly (or not ideal) force those ideas onto Git usage. Hence the reason I said it takes a bit or "rethinking the problem", and in the end everything becomes quite clear.

For those interested, read the many blobs about how the Linux Kernel development is managed. Or even how Git's development itself is managed. True distributed workflow models.

Regards,
Graeme

FPC is a compiler and not an OS kernel, so would like to see such blog posts from big compilers: e.g. gcc, clang

Hi,

Ok, to put this into practical example: lets say some idiot decides to do a Webassembly codegenerator for FPC. This idiot starts working on his working copy, but quickly loses track... So he wants to start committing his changes. But in SVN, this idiot has to either:

A., create a Webassembly branch and start committing there, polluting the global SVN repository forever, even if he's demotivated after 5 commits, and never touches that branch again. (...)

B., keep his changes in his working copy forever, getting in the way of other changes, and causing endless conflicts with changes coming in from trunk.

C., keep two working copies, in case he want to work on something else meanwhile, and want to avoid accidental commits

(D., use git-svn, and create a local only branch - sic!)

Now, in Git, this idiot can do:

1., Have his own clone of the FPC repository. Create his local webassembly branch, and keep happily working on his local copy, then leave it rot when he loses motivation, doesn't distract anyone.

2., If he wants to involve others, he can publish his whole repository as FPC-Webassembly project, independently from the main repository he forked, and get others working on it. At this point his repository acts like an independent fork of the compiler.

3., If his project succeeds (independent from the number of people worked on his fork), then he can issue a pull request, while asking a review from seniors on the FPC project. He can still do the changes requested from him on his own repo, and commit them easily.

4., He can still sync his own repository with ease with the main FPC project. So he can be sure when he sends his pull request, it will merge seamlessly against the FPC master. (And this is in fact should be expected from him.)

From the two above, I would go for the Git option. Because we're already

stuck with the first one in SVN, and it's not good. ;)

The bigger picture is, that I can do the SVN branch, because I had write access to the SVN. But people without commit access, can't. So this also makes difficult from people independent from the project work on larger scale changes on their own... Or if they still do (hello NewPascal!), because git-svn allows them, it's difficult for us to integrate their changes back...

Charlie

... and the code is lost :)

In our previous episode, Karoly Balogh (Charlie/SGR) said:

Trust is that people are not deliberately doing things. For accidental things there are tools (except GIT, apparently)

Yeah, blabla, distributed, anarchy, world domination. I though I did mention I wanted practical info?

I was not asking for ideally. I was asking very specifically how a GIT in a FPC team group would work.

And no, sending 40+ pull requests to all members of core does not count. So there is one golden repo and that is what I'm talking about.

easily. It's the responsibility of the maintainer of a given branch to accept that pull request or not, or request further changes before its accepted.

So tool failure is fixed by throwing manpower at it?

We don't have an approval person now, so a requirement to that would IMHO be a dealbreaker for GIT.

I would like to have lots of extra manpower too, but I rather not spend it on what in practice would be rubberstamping commits (and delays in distribution till something is approved if the reviewers are AFK).

This is exactly what I wanted to avoid with the primary case posed in this subthread: how to avoid blocking the central repo for commits (from a practical viewpoint)

At work, I don't even push against master, but I do a pull request against my own repository, and ask one of my senior colleagues to review... I don't know about you, but to me this sounds a lot more like teamwork, than going around beating up people "for wrongdoing" with a cluestick.

Then you don't understand what I mean. In the job you go see the person, work something out, and problem sorted in a few minutes. The odd impossible person is usually swiftly dealt with.

In distributed, volunteer driven, projects, people are away/nonresponsive for extended periods of time, working hours (and days) don't match. Also working this out via mail is much less productive.

I know what an honor-system is. It doesn't protect against mistakes the day before holiday. Remember the old locking VCSes ?

Sorry to say, but I didn't find anything new or usable in this post. It is the standard "think different" nonsense from a very idealist viewpoint, little practical details.

So I now give up this thread (and GIT).

Hi,

I see your point Florian, but at least LLVM seems to have a Git gateway these days, and they documented how to contribute using Git, while they can keep their upstream SVN.

http://llvm.org/docs/GettingStarted.html#sending-patches-with-git

And the same with GCC:

https://gcc.gnu.org/wiki/GitMirror

The important fact to see is Git allows people do their own branches (local branches, of course) and forks much easier/cheaper in a way, which also makes easier to contribute their changes back to the main project they originally forked. This part is at least is independent from the nature of the software developed, and the poIitics involved, I think.

Charlie

So first problem identified: no git mirror of the full fpc repository :)

Hi,

Marco van de Voort wrote

Trust is that people are not deliberately doing things. For accidental things there are tools (except GIT, apparently)

Err...? :) The only way to can fuck up a remote Git repository is by force pushing, if you have write access already. But you can disable force pushing even for people with write access. (Which is advisable.)

I was not asking for ideally. I was asking very specifically how a GIT in a FPC team group would work.

See my other mail.

Honestly, I can't even... You sound like the Expert Beginner Twitter account. No personal offense intended, but you just do.

In distributed, volunteer driven, projects, people are away/nonresponsive for extended periods of time, working hours (and days) don't match. Also working this out via mail is much less productive.

So it's much more productive to just give everyone commit access to the main repo, and let it being polluted with random branches? Or anyone who wants to contribute but not with FPC for years, should keep working on his working copy (with no ways to commit) and then submit a .diff via Mantis?

(Well, people are smarter than that, fortunately, so they just use git-svn. Whatever.)

Sorry to say, but I didn't find anything new or usable in this post. It is the standard "think different" nonsense from a very idealist viewpoint, little practical details.

Err, see my other mail about a practical example.

So I now give up this thread (and GIT).

You should try to use it. For once. With an open mind. I know it's hard.

Charlie

Karoly Balogh (Charlie/SGR) wrote

so they just use git-svn.

This is what I do as well for several things, but I still think, subversion is the better solution as the canonical FPC repository.

Hi,

Florian Kl?mpfl wrote

> so they just use git-svn. This is what I do as well for several things, but I still think, subversion is the better solution as the canonical FPC repository.

*shrug*

As I said, I'm fine with it anyway, whatever. But I can see the practical reasons for Git, and see the reason why people would want it. And I came a *loooong* way to admit that. In late-2009 early-2010 I sounded more anti-Git than Marco. :)

Charlie

Florian Klämpfl wrote

FPC is a compiler and not an OS kernel, so would like to see such blog posts from big compilers: e.g. gcc, clang

OS Kernel, Compiler, any other project - what's the difference. Git development itself is managed in a very "distributed" way with multiple branches, maintenance releases etc. And more impressively, all branch merging is done by a single person. Their processes are quite well documented, and if you see how active the Git development is, it goes a long way proving that even a very active project can be managed by very few (one in this case).

My point is, you can learn from them to see how a project can be managed without adding extra work-load to one person or a small team (like FPC).

Regards,
Graeme

Karoly Balogh wrote

Now, in Git, this idiot can do:

Plus that idiot could start the fork and his branch without needing to bother the FPC team. With SVN he has to ask them to add him to the SubVersion repo user list, create a branch, and manage his user permissions for that branch.

Git = KISS is this case. ;-)

Regards,
Graeme

Florian Klämpfl wrote

... and the code is lost :)

Not at all, I have about 20+ local branches in my fpGUI repository. Some branches date back to 2009, 2010. Ideas I had, but lost motivation, or they were simply an experiment (that could be useful at some point). Just 2 days ago I revived a 5 year old branch and finally completed the work.

I didn't pollute the public fpGUI repos because it was personal ideas or features I toyed with. They are in various incomplete stages, or simply experiments. I don't want others to see such work until my ideas have matured.

On the flip side, in the past I have seen newsgroup posts where somebody has similar ideas to one or two of my incomplete branches. In such cases I speak to that person and if interested, I publish such a branch to begin collaboration.

Regards,
Graeme

I use it every day.

When I hired someone for a bounty, he introduced me to it, and I have been using it ever since :-)
p.s. Thanks Dmitry! ;)

It's my stubborn old practice of not wanting to learn a new tool, Git, when SVN was working quite fine for my needs, but I do admit I don't have experience working with thousands/hundreds of developers all on the same repo, I more use it for my own need.

it may just be a github thing, I'm not sure. Not git, possibly, but github has an SVN bridge that allows you to treat a github repo just like an SVN repo, and run svn commands.
I use total commander for most of my SVN work with tortoise svn, which sounds like I am some kind of newbie/beginner since I don't use command line much, but it serves my need very well visually committing which files I need, which IMO is faster and more productive than running 5 different commands on files I have to manually type in or keep pressing the up arrow to repeat old commands (seems like 1970's way of doing things on unix, which I avoid) But I guess that is another issue.

The point is that github does in fact allow you to treat a github repo like an SVN one, so I wondered if Florian had tried this - but I guess you might as well use SVN if you are going to make github "like svn" instead of actually being svn. Key advantage: use github awesome web interface gui, plus have svn like revision...

IMO the big success of git is not git, but the github website which is visually stunning, beautiful, and productive - along with being a great social tool (although, I'm not so social). Only gripe I have about github is the fact that you cannot search forks! Searching forks on their website is essential for finding other people's code, and you cannot do that. you can't search any forks??? wtf..

DaWorm wrote

emacs! vi! Let's call the whole thing off and use EDLIN.

Don't forget mg

https://www.google.ca/search?q=mg+micro+gnu+emacs

From what I remember, this one had some nice simple C source code instead of bloated projects..

He's talking about Army of Programmers in a Building, an article I wrote years ago ;-)

Sometimes it's better to just walk over and talk to a real programmer in a real building than it is to send some email over the christmas holidays and wait 2 weeks for a reply for him to commit his changes.. since he's in Barbados or Cuba on vacation.

With Army of Programmers in a Building you can just go and knock on his door, or his cubicle, instead of this pathetic thing called Email.

The disadvantage of working in the same town/building as someone, though, is that they may always be bothering you non stop and tapping on your shoulder, but not really since programmers aren't that obnoxious, AFAIK

This development on the internet across multiple countries has some massive disadvantages to something like the Microsoft Campus where you can go over and knock on the guys door, or at Borland (although, they are hiring people offshore AFAIK now)

And sometimes typing out a long email takes time, instead of just being able to speak in real time to a real person - an email is like a fixed essay, whereas a conversation is in real time, instant. They have IRC for this, I guess, but that becomes addictive and wastes lots of time, IMO, and you don't get as much work done if you are chit chatting nonstop on irc/icq/message systems

Yes but forking is a double edged fork (sword)...
You can fork so easily that no one actually works together and then you have 218982 versons of emacs floating about that no one actually uses, because so many forks splits up the userbase and then everyone just ends up using a central version of emacs, the main copy

Git = KISS is this case. ;-)

Everyone making thousands of forks and not working together is not simpler, it's just a different way

I like the ability to fork, as I am sick of developers not allowing me to make some change, and I go off and work myself on some fork but.. it's also anti-social and leaves projects in so many forks that no one works together. Everyone forks github repos and then you cannot search the damn code on github, as forks are not searchable - so no one can find good updated code, you just see the main git repo, which, is kind of like having a central svn repo! but with thousands of stale forks???

I'd rather upload/commit files to a server to insure it is backed up properly...

What happens if your hard drive becomes corrupted and fails, with a local git?

This has happened to me so many times, hard drives have failed on me (no knock on wood)

But I'm not so familiar with git so wonder what happens. Don't you eventually have to start uploading to a server anyway, at some point? As you cannot trust a hard drive.

But what happens with corrupted or failed hard drive on your personal computer? Do you have any backups or is this local git work only on one personal hard drive that could fail at any time?

Sorry, I've just had too many hard drives fail on me... so many fail that it's almost as if someone was doing it on purpose to me.

Do you make some backups on a usb stick or some server elsewhere no one can see?

I'm not just talking about 8 space indentation vs 4 space or 2, I mean having to put code
{
{
{
here

Instead of fpc/oberon/golang:

func {

code here

or

procedure TSomeObj.Example
begin
code here

instead of

...
...
...code here

Just to do basic bloody damn things, Java and C# require ridiculous obnoxious nests/indentations.

No talking about 2 vs 8 space indentation choices, although that's another issue

Pascal and C are actually twin brothers with slightly different syntax...

But my biggest hate for C is not C itself but just the one fact that it lacks strings.

Without strings, a language is headed for the graveyard, IMO.

Counting pchars in your head is just a waste of brain power..

The C struct is literally the pascal record, and is all based on the same Structured Programming work by Dijkstra

But the virtual machine is just C code, so it's a wrapper around C, IMO

I could be wrong, but, all it does is end up calling C written VM, right?

The C struct is literally the pascal record, and is all based on the same Structured Programming work by Dijkstra

except that the C struct does not have the array length at position zero and you have to process until you hit the first null character... that's the plus for pascal strings... you know how long the string is from the start... unless it is a unicode string ;)

Just to do basic bloody damn things, Java and C# require ridiculous obnoxious nests/indentations. > No talking about 2 vs 8 space indentation choices, although that's another issue

i'm guessing that you haven't played with python where indention is a major aspect of the language ;)

Well, the problem is that you can't use those handy Pascal strings that much anymore these days. Ever since you need to use UTF8 to properly represent textual context, this all has become one hell of a mess, pretty leveling the playing field when it comes to handling such strings with (Free)Pascalor C...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

And like I explicitly said, read the well documented processes followed by the Linux Kernel or on a much smaller scale, the Git development itself.

I would like to have lots of extra manpower too, but I rather not spend it on what in practice would be rubberstamping commits (and delays in distribution till something is approved if the reviewers are AFK).

Once again, read how the Git project deals with it. That workflow could suite FPC quite well. In summary, feature are in separate branch. There is a public "testing stablish changes" and a public "testing unstable" branches. Everything stays in branches until they are signed off and merged into "master" (aka Trunk). Then less than 5 minutes is spend doing a "octopus merge" of all branches that have been well tested and signed.

If you don't know, a octopus merge is a single merge command but merges 2+ branches all in one go. eg:

git checkout master
git merge feature1 feature2 feature3 feature4 feature5

...where "featureX" is a branch name.

Unlike SubVersion, you don't waste a whole day "rubber stamping" commits. Such micro-management doesn't exist in Git. Git was designed to work better that SubVersion, and specificall at branch management and merging.

Hence my earlier WTF comment when I read the LLVM team want- to ban merge commits! That person clearly has no f**ken idea how Git works.

In distributed, volunteer driven, projects, people are away/nonresponsive for extended periods of time, working hours (and days) don't match. Also working this out via mail is much less productive.

Then simply don't pull or merge their work. Simple as that. Once again, you are thinking in terms of SubVersion. Don't!

You don't see the Linux Kernel project come to halt when somebody fucks up a commit - they just don't merge that commit or branch until the idiot fixed his work. And neither do they have communications problems via emails or the mailing list - they have tens of thousands of contributors spanning the globe. So I don't understand why you think such a small project like FPC will have communication issues. That's just laughable.

Sorry to say, but I didn't find anything new or usable in this post.

Actually, it's only your stubbornness showing. I thought Karoly's reply was very informative.

Regards,
Graeme

I like the ability to fork, as I am sick of developers not allowing me to make some change, and I go off and work myself on some fork but.. it's also anti-social and leaves projects in so many forks that no one

"fork" is probably the wrong word. I prefer the word "clone" instead. It is only anti-social if YOU (the developer) don't share your changes. You do that by sending a pull request to the original project.

See...

git help request-pull

...for more details. And no, you don't require GitHub for pull requests, it's built right into Git.

Regards,
Graeme

Florian Klämpfl wrote

This is what I do as well for several things, but I still think, subversion is the better solution as the canonical FPC repository.

The ‘git-svn’ functionality is great - I use it for several SubVersion projects too. It also unfortunately stops you from using many of the nicer features of Git. So you definitely don’t get the full experience - it’s more like the “cheap seats” at a concert. You can say you were there and heard the band sing, but you couldn’t actually see them.

Regards,
Graeme

El 24/05/2017 a las 8:57, Graeme Geldenhuys escribió:

My company uses svn and I use git for my local work since Mr Geldenhuys praised it a year or two ago ;-). For me, branching is the really the big thing. I have several branches running, and I only commit to svn repository after testing everything.

Git is complicated, I don't mean it is overcomplicated, just it's more complicated than svn because it tries to accomplish more and more complicated tasks than svn. In fact, the discuss shouldn't be svn vs git, but centralized version control vs distributed version control. Nevertheless, git has a complicated and anti-intuitive command line syntax. Git is the winner over others, like Mercurial, because of Linus Torvald's popularity, not that Git is better or worse than Mercurial, just that their technical virtues had little to do with the success of git. I use Easy Git, It is a perl script that In the background it calls git, but syntax is more sensible.

i.e. instead of

git checkout master
git checkout develop

eg switch master
eg switch develop

Yes, that's very handy... and scaring.
The merge is done magically in the repository, not in a working machine, It is a little black box. But it's looks that it manages to do its job. Nevertheless I have had some unexpected issues... it is scaring. :-P

Should I recommend git for central repository in my company? Not sure. What's the difference between pulling from several repositories and pushing to a central repository? In the end, I prefer the central repository with a more lineal history. I think that distributed development works better when there is a big project with independent parts. For me, in Git is much important de advantage of easy local branches that distributed development.

On the other hand, probably I'm getting old ;-) :-(

Nothing stops you from using a remote git server on some private remote hosting server, that gets backed up regularly.

Or having a dedicated git server in your LAN, that you regularly backup.

Or indeed, make regular backups of your working directory, on one or more external media;
it's as easy as COPY THE ENTIRE DIRECTORY.

-L.

But what happens with corrupted or failed hard drive on your personal computer? Do you have any backups or is this local git work only on one

I used to live in a country with constant blackouts or brownouts. So harddrives took a real punishment. UPS's were a requirement, not a luxury. So I take data protection very seriously, even though where I live now the power is much more reliable and clean.

Yes, I have off-site private backups, and on occasion I push those to a USB stick too. Everybody should at least be doing this.

I also know how valuable my work and data is - I run my own business. All my data, code and VMs lives on 4 server quality harddisks using ZFS RAID-Z2 as the file system, and FreeBSD as my OS of choice. I will not trust my data on anything other than ZFS. Even my USB sticks use ZFS. My hard drives were bought from different suppliers so they aren't all from the same batch. I also replace them every 3-4 years (ZFS makes this a no brainer).

I highly recommend you read up on ZFS if you don't know it. It comes natively with Solaris and FreeBSD, and is easily installed on Linux. I believe OSX might also have unofficial support now.

ZFS is a copy-on-write files system. Every read and write is checksummed. I can have two hard drives fail (very very unlikely) and still be able to rebuild my data. Very sensitive data I store in a partition that keeps two copies of the data scattered around the ZFS pool. ZFS partitions can be created and destroyed on the fly - they are more like directories than partitions. So you can create and destroy partitions as the need arises, and set encryption, compression, de-duplication etc on each partition as you see fit.

Sorry, I've just had too many hard drives fail on me... so many fail that it's almost as if someone was doing it on purpose to me.

Sounds like you are in serious need of ZFS. If you work on a laptop (so can't install 3+ hard drives), then I recommend you get one of those USB3 or Thunderbolt port external NAT-style storage devices. I know some of them support ZFS. But those storage devices are a bit costly. But then, how much is your data worth?

Regards,
Graeme

But the virtual machine is just C code, so it's a wrapper around C, IMO

That is way over-simplifying it I would think.

I could be wrong, but, all it does is end up calling C written VM, right?

Technically, you can write a VM in many other languages too. I honest don't know what language they use for the various VMs out there - but I guess C is a safe guess.

Regards,
Graeme

In our previous episode, said:

The scenario was based on older commercial VCS systems (VSS, that Team thing from Borland etc etc) that required explicit locking, and people would lock files, change some formatting and then go on holiday before their real work started. During that time nobody could make changes to those files, and even back then we already had some form of CI to a testserver that worked from the VCS, so that also hampered testing your own mods.

Locks were notorious hard to break, and persons with the required rights were often also rare during those periods.

And yes, if you did that, specially if the file was something central (like a file that listed all commands accepted by the command processor), people could get somewhat aggressive ;-)

The DVCS scenario is not as bad, but some simple prevention of this would prevent some mistakes, and make the minefield for new devels a bit smaller, thus save a lot of annoyance on all sides.

line much, but it serves my need very well visually committing which files I need, which IMO is faster and more productive than running 5 different commands on files I have to manually type in or keep pressing

Git includes as standard all the GUI tools you would ever need. Plus those GUI tools are available on all platforms that Git supports. So there is no retraining in different tools for each platform. eg: Tortoise Git is only available on Windows. So if you jump to OSX or Linux or FreeBSD, you need to learn a different tool.

Anyway, the standard git GUI tools...

* git gui: visually make commits, do branch management, selective line-by-line commits, pull, push, merge etc.

* gitk: visually see your commit history. For a specific branch, or all branches in the repo. You can also cherry-pick commits from one branch into another.

* gitk -- <file> See the full history for a specific file only, or for a directory only.

* git gui blame: visually see line-by-line who made which changes.

All these gui tools also have built-in navigation, where if you click on a SHA1 it navigates to it.

The point is that github does in fact allow you to treat a github repo like an SVN one,

Ah, I see that now. I never knew that existed. It is definitely a Github only thing.

Regards,
Graeme

I'd rather upload/commit files to a server to insure it is backed up properly...

There is absolutely no guarantee that your file are any safer. So you have your Army of Developers in a single building. You store all your files on a Server which is in the server room in the basement of the building behind steel doors. Oh wait, a Boeing 747 fully fuelled just flew into your building. Everything is now a pile of rubble. Oh the backups where on another server next to the one you pushed changes to.

;-)

Regards,
Graeme

Florian Klämpfl wrote

First problem: quote from core:

The git-to-svn bridge is slow, but pretty good - not perfect, sometimes it falls over and needs a restart. But I can honestly say, I have converted full SubVersion repositories (from small to very large) to Git, and always managed to have everything in Git at the end.

Nobody ever stated that any type of migration is going to be without problems. It's the nature of migration. I've stated numerous times that SubVersion is often abused because they have very bad concepts, which have been clearly designed and developed in Git. "Tags" are the first thing that comes to mind.

Back in 2009 (I think it was) when I created Git mirrors of FPC and Lazarus, I initially did it with all branches and tags in place. It took long, but there was no roadblocks. The only reason I then changed it to only track the "trunk" branches is because I personally think a migration should be a one-shot deal, not a continuous process. It was a pain to manually update and work around the weird SubVersion behaviours (commits after a Tag was created - God Damn, use a branch instead!).

Over the years I've personally migrated over 200 SubVersion repositories to Git. My final step has always been to checkout each SVN repository and branch, and then do a checksum comparison to the Git version. Ensuring everything is like it is supposed to be. Any discrepancies can then be resolved with a single commit, but to be honest, I can't recall ever having the need to do that.

Regards,
Graeme

Hi,

Graeme Geldenhuys wrote

Back in 2009 (I think it was) when I created Git mirrors of FPC and Lazarus, I initially did it with all branches and tags in place. It took long, but there was no roadblocks.

I think the claim was, after the svn 2 git conversion, some commits were missing from the converted repo, at least the one the FPC Team had internally. As in, the history wasn't complete. Not sure what that means though, or which commits, commits of which nature, or why. Maybe Florian can ellaborate on this.

Charlie

Git has built-in support for alias. So you could simply define a couple of aliases in your $HOME/.gitconfig file that mimic the above commands, or even the SVN commands. I have over 20 aliases that I created over the years to simply long command line parameters.

For example:

   $ git config --global alias.switch checkout

will result in the following

---------[ ~/.gitconfig ]---------
[alias]
st = status -uno
svnlog = log --stat=70 --pretty=medium --name-status --reverse ...snip...
switch = checkout

----------------------------------

Now suddenly I can do this:

   $ git switch develop

No need for Perl add-ons. ;-)

ps:
Above I listed two of my most used aliases as well. I have plenty of others too.

Everything is done locally first. So if you are not happy with the result, it can be undone with a simple git-reset command.

Regards,
Graeme

Apologies for the poor threading, but not all ML messages get through our gateway.

Thanks for the explanation Graeme, I hope that I'm not the only person here to find that instructive. So in the context of what I asked

says explicitly that the modification with the hash g45f932c1 takes the project on the Git repository under consideration to something that could usefully be described as v1.4.1-787, and you can use that in conversation without having to be online to a repository.

If multiple people were committing directly to the same repository (I presume Git supports that) presumably they'd see a consistent sequence of version identifiers, i.e. very much like Subversion.

What happens in the case where there's multiple repositories? How brutally would each one have to be whacked before it was guaranteed that every one had the same correspondence of release-commit tuples and hashes? Could this be /forced/ at the project level and what implications would that have on the amount of data transferred to synchronise them?

Karoly Balogh wrote

missing from the converted repo, at least the one the FPC Team had internally. As in, the history wasn't complete. Not sure what that means

The bottom line is, the end result should be identical to what you see when you do a 'svn co' on any branch, compared to the Git migrated version. At least this was my case in all the conversions I have done.

Some of the git-svn output is weird though. They sounds more alarming than they really are. eg: If you had a commit that only changes svn properties, I believe sometimes git can skip over such commits because there is no direct translation to Git. But those are generally rare, and often not an issue, because it was more SVN repo maintenance that actually tracking changes to files. The latter being way more important.

If the Free Pascal team is ever serious about migrating to Git, I'll happily help out with the migration process.

Regards,
Graeme

I agree, it's really very good indeed and I think the only reason that it's not more widely used is the licensing problem (Sun's license being incompatible with GPL) which resulted in a lot of FUD.

But my biggest hate for C is not C itself but just the one fact that it lacks strings.

I also hate the cryptic syntax, the fact that there is *.c and *.h files etc. Apparently Java took a lot of ideas from C, but at least they had the common sense to get rid of the *.h file mess, and the Object Pascal "interface" vs "implementation" section mess! Kudos to them for that. Navigating Java code is so much easier now.

Regards,
Graeme

But in Object Pascal you have...

  begin
     ...
     if <whatever> then
     begin
       ...
       if <whatever_else> then
       begin
         ...

Object Pascal blocks are longer to type - “begin” vs ”{” and “end” vs ”}”. Also IF statements require the extra “then” keyword etc.

As for indentation. At least with real TAB character indentation, you can configure the width of a TAB as a user configurable parameter without affecting the source code. With space indentation you are stuck with whatever the original author did.

But lets not get into Space vs TAB vs Elastic Tabstops indentation/alignemnt arguments - that’s a whole new war I don’t want to tackle. :)

Regards,
Graeme

quite true, my friend... quite true :)

Hi,

Graeme Geldenhuys wrote

If the Free Pascal team is ever serious about migrating to Git, I'll happily help out with the migration process.

Well, I think the resistance is too big for the migration. The SVN people go full berserk bloodbath mode when Git is mentioned, and Git people usually go "whatever" and just use git-svn. :)

But. If we could come up with a way, which allows accepting pull requests with Git somehow (thinking about Github, specifically, but in general), then have them seamlessly integrated into upstream SVN as they're accepted, that would maybe move things forward. (Remember, we even have an FPC organization on Github, which we can utilize.)

With the more automated verifications regarding the integrity of the SVN the better. But Marco was right on the point, that this needs a very very carefully designed plan and process, to not screw up the upstream SVN. Maybe what LLVM and GCC has in place can serve as a starting point.

And to be honest, I wouldn't even have the full SVN mirror "published" in Git, only trunk, and branches fixes_3_0 and newer, with the later being read only, as merges would happen by the maintainer, in SVN.

So yeah, TL;DR: instead of trying to fix people we could use engineering to make the technology just serve us all. :)

Charlie

Mark Morgan Lloyd wrote

s the licensing problem (Sun's license being incompatible with GPL) which resulted in a lot of FUD.

It's only a problem if you want it to be. Yes, they can't include ZFS as standard with a Linux Distro (though some now apparently do), it is is pretty much a two command step to get it installed.

1) // Add the add-on apt repository to your list
2) apt-get install zfs

Something like that - its been a while since I did that in my dual-boot Linux environment. Also ZFS doesn't run via FUSE on Linux any more - it is a "native" file system now.

https://launchpad.net/~zfs-native/+archive/ubuntu/stable http://zfsonlinux.org/

The really good news is that for some time now, all ZFS development is merged into a single organization. So OSX, Linux, FreeBSD all have the same ZFS features and functionality. No more fragmented development.

Regards,
Graeme

The virtual machine is a JIT compiler, so it recompiles the bytecode to machine code for the current CPU, *not* to C code, so your understanding is not very accurate.

I could be wrong, but, all it does is end up calling C written VM, right?

What does "calling" a VM even mean? The VM is like a compiler, it translates java bytecode to machine code. It can also be implemented as an interpreter (and probably ancient versions of the JVM were interpreted), but that makes the program run much slower, and it can never compete with compiled code in this case.

Nikolay

Yes, this is one of the horrible things I have beef with. I have several.

1) the null terminated "strings"
2) the fact that the array size is not exactly part of the type. In case you're wondering what this means, if you declare:

int a[5];

sizeof(a) gives you the correct size of the array. However, if you pass this array as a parameter to a function:

void func(int array_param[5])
{

         // inside the function, sizeof(array_param) gives you the size

of a pointer, and not the array size
}

That's one of the reasons you can't add range checking to C compilers.

3) the fact that you can get easily burned by typing '=' instead of '==' (or vice versa).

Both

   if (i=5)
     do_something();

and

   i==5;

Will happily compile and _not_ do the expected thing. Modern C compilers give you warnings in these cases, but that doesn't change the fact that this is bad language design. Bonus points for the fact that writing this ugliness:

   if (5 == i)
     do_something();

is considered a very good practice by some people, just because it prevents you from being burned if you write if (5 = i) instead :)

4) the badly designed standard library. Even though C "strings" suck by design, the library functions, that operate on them have extra hidden traps. For example, using strcpy is unsafe, because it doesn't check the size of the destination buffer, that's why you must use strncpy. However, this code:

char dest[1000];
strncpy(dest, src, sizeof(dest));

is still unsafe. Why? Because if src is 1000 characters or larger, even though strncpy will not overwrite past the end of the dest array, it will _not_ put a null terminator in the dest array. On top of that, it is also suboptimal - if src is shorter, strncpy will fill the entire array past the end of the string with null characters. So, if src is a 10 character string, strncpy will write 990 null characters, filling the area between dest[10] and dest[999], wasting CPU cycles on that.

Nikolay

Yes, you can use "v1.4.1-787" to describe a specific point in history, but the far more common and useful one is the "45f932c1" SHA1 reference, because the latter can be used directly in all Git commands.

If multiple people were committing directly to the same repository (I presume Git supports that)

Yes.

presumably they'd see a consistent sequence of version identifiers, i.e. very much like Subversion.

Yes. A SHA1 reference like "45f932c1" only only points to a specific commit, it also describes the history that lead to that point.

Let me explain: Say you have two branches with the same file, and the file hasn't actually changed between those two branches. Now say I give you a patch file to apply to that file in both branches. The commits that gets generated in each branch - even though the diff is identical - will not have the same SHA1 reference. Because the history to get to that point has diverged because of the branching.

So if I mention a problem in the "45f932c1" commit of a Git repository. No matter how many clones [by multiple developers] there are of that repository, that SHA1 reference will point to the exact commit and code change - in all the Git repositories out there in the wild.

This is also one of the huge arguments about NOT using the git-rebase command on a branch that has been published, because a rebase command rewrites the history. So every commit (SHA1 reference) in that affected branch changes. Rebasing local branches (not made public yet) is obviously not a problem.

The Git project repo has a "short lived" branch where they do all kinds of testing. They explicitly note that nobody should base any new development on that branch, because it will frequently be destroyed and recreated (merging in new feature to be tested for the next cycle).

What happens in the case where there's multiple repositories?

No difference. A git repo contains the full history. If you clone that repository 100 times between developers, you effectively have a 100 backups. If the original repo had 5 branches, all 100 clones with have references (and full history) to those 5 branches too. Such remote branch can be listed using the following command:

git branch -r

eg:

[tiopf (tiopf2)]$ git branch -r
carlo_marona/Add_tiLogToDebugString
carlo_marona/Additional_Mediators
carlo_marona/Fix_BOOLEAN_Defines
carlo_marona/Fix_TtiDatabaseZeosAbs_SetConnected_Except carlo_marona/Fix_tiCriteria_AssignClassProps
carlo_marona/Fix_tiMediatorView
carlo_marona/Fix_tiModelMediator
carlo_marona/Fix_tiQueryZeosIBFB_Unit
carlo_marona/tiOIDManager_Update
carlo_marona/tiopf3
github/master
github/tiopf1
github/tiopf2
github/tiopf3
sourceforge/HEAD -> sourceforge/master
sourceforge/fea_Fix_Event_Execution_Of_TtiPropertyLinkDef sourceforge/fea_Missed_Changes_On_tiOPF3
sourceforge/master
sourceforge/tiopf1
sourceforge/tiopf2
sourceforge/tiopf3

Here you can see my local tiOPF repository has 3 remote repositories defined. "carlo_marona", "github" and "sourceforge". I frequently pull fixes from Carlo, so that is why I have a permanent remote repository link to his published work. For contributions from one-off developers I don't bother setting up a remote repository link - I use their repository URL directly in the git-fetch command.

The official public tiOPF repository lives on SourceForge.net, so that is the "sourceforge" remote repo link. The "github" link was just a backup public repo I used while SourceForge.net had a major global outage a little while ago. So development continued as usage without skipping a beat (thanks Git).

You can also see from Carlo's repository that he nicely names each branch, and every branch that is a bug fix has the prefix name "Fix_" to it. In the end you can name branches whatever you want though, and you can even groups things with a "/" in the name of the branch.

Regards,
Graeme

Hi,

Pascal and C are actually twin brothers with slightly different syntax...

Fortunately, they really aren't. :) And this goes both ways.

But my biggest hate for C is not C itself but just the one fact that it lacks strings.

Strings are a library feature, with syntax sugar on top of it. Nothing stops you to implement Pascal-alike strings in C, minus the syntax sugar. In fact I'm willing to bet, there are some libs out there already, ready to be used. In fact, see what someone wrote about UTF-8 later in the thread, pretty sure you can just pull in an UTF-8 string library in your project and run with it...

There are a bunch of things in C, which are a lot more WTF.

1., no standard way to determine the length of an array compile time. sizeof() returns the length in bytes, not the number of elements. Basically you have to do sizeof(array)/sizeof(elementtype), where the elementtype has to be the same as when you declare an array.

2., I cannot make an enum type, and make an array which matches that enum type, and has the same number of elements, other than arbitarily defining the "max" item in an enum (no low()/high()/length(), etc). Same with standard types, actually (talking about things like array[boolean] of <type>). Also, the compiler makes no checks that if indexing this array[type] is out of bounds when used. This single thing alone makes it super robust to write all kinds of low level Pascal code, when used properly. Which is of course also possible in C, but you don't get the safety-net of the compiler/language, so you end up writing a billion tests for all kinds of edge cases, which cannot even happen in Pascal.

3., While we're at enums, the size of enumeration type is not defined, except it's "int" which varies wildly from platform to platform. Which means if you cannot really have enumeration types in structs which are involved in I/O, otherwise you're up for surprises. There are ways around this, but it's very cumbersome, so usually people just go "whatever" and hardwire an int type of arbitary size instead. But then again, you lose all kinds of compiler checks.

4., The whole weakly typed thing. You can have all your types defined, but when you mess up, the compiler just says "well okay" (even with -Wall), especially when you pass around various pointers, and you end up scratching your head, what makes your code explode.

I'm working as an embedded software engineer these days, in C/C++, these were the just the things I ran into recently. Strings are the least of the problem, when it comes to defining an architecture in C in a safe/sane way. :)

Charlie

(Ps: BTW, fixme on any of the above, I don't even claim I'm good at C, so at least I learn something. Also, I know C++ fixed some of these, which is among the reasons why people stick to a subset of C++. "C with classes", as they say, I say, it's "C with classes and stronger typing." ;) )

It's even worse than that - see my other mail. Even the size in bytes is lost, as soon as you try to pass that array as a parameter to function, since it gets implicitly converted to a pointer, and the size is lost, because... who cares about array sizes, this is C! :)

Nikolay

El 24/05/17 a les 13:02, Graeme Geldenhuys ha escrit:

Or use mercurial with tortoisehg (note:when I switched from cvs to mercurial, git was not available for windows, while mercurial was already stable and multi-platform. I cannot claim I understand mercurial fully, but at least I can use it for basic tasks with no surprises, while my experience with git is like https://xkcd.com/1597/)

$ LC_ALL=C git gui
git: 'gui' is not a git command. See 'git --help'.

Did you mean one of these?
gc
grep
init
pull
push

Bye

Hi,

Ah, I love this. :) Thanks for this, I didn't know. Will put it on my list. :)

These are nicknamed Yoda conditions. :)

OK, this is also beautiful, thanks again. :) BSDs seem to have strlcpy() tho', which works around both defects mentioned here, but that's non standard obviously, because who needs standard functions which make sense. :)

Charlie

Luca Olivetti wrote

$ LC_ALL=C git gui git: 'gui' is not a git command. See 'git --help'.

I guess you can blame your Linux distro's rubbish package management requirement policies for that. They probably split Git into two or more packages. F**ken annoying if you ask me - hence I don't use Linux any more.

I compile Git from the original source code, and it includes everything... Console, GUI and SubVersion support.

Regards,
Graeme

Graeme Geldenhuys wrote

I compile Git from the original source code, and it includes everything... Console, GUI and SubVersion support.

On this web page the first two screenshots are of gitk and git-gui - the standard GUI tools of Git.

https://git-scm.com/book/uz/v2/Git-in-Other-Environments-Graphical-Interfaces

They might not look as visually pleasing (eye-candy) as many other gui tools, but trust me, these built-in apps pack a punch (tons of features), and always supports git very well - obviously.

Regards,
Graeme

El 24/05/17 a les 16:03, Graeme Geldenhuys ha escrit:

Right, unsurprisingly it's in the git-gui package.

bye

I have my doubts about availability of the GUI component for OS/2, but you're welcome to prove me wrong. ;-)

Tomas

Maybe with Alias I don't need eg to redefine git CLI. But IMHO it clearly shows how poorly git defaults and parameters have been chosen. And I am afraid that has been one of the hinders of git adoption.

Here is an overview Easy Git (eg) parameters
https://people.gnome.org/~newren/eg/documentation/ I think it shows how git parameters should had been.

Santiago A. wrote

But IMHO it clearly shows how poorly git defaults and parameters have been chosen. And I am afraid that has been one of the hinders of git adoption.

The problem goes much deeper than that. I once brought up the issue of inconsistent command line parameters in the Git mailing list and gave ideas I thought were improvements.

They immediately confirmed the problem, and the problem in finding a solution. Some issues raised:

* Because git has so many options (way more than normal apps), one change can (and does) have affects on others.
* Backwards compatibility. Changing the commands will break just about every Git GUI front-end there is. Many of them simply parse the output of a forked 'git' command. But they would actually consider doing this for the greater good - I was impressed.
* Conflicting command line parameter "modes".

If interested, the discussion can be found here:

Regards,
Graeme

Tomas Hajny wrote

I have my doubts about availability of the GUI component for OS/2, but you're welcome to prove me wrong. ;-)

I haven't personally tried Git under OS/2, but I have two OS/2 VMs available, so I'll test.

Does OS/2 have a port of TCL/TK? That's what those GUI's are written in.

Regards,
Graeme

Thanks very much for that, very interesting.

I could find a port of Tcl/Tk version 8.3.5 on Hobbes. No idea if there are newer ports somewhere else.

Tomas

ROTFL, didn't know that :)

Of course, it's still not standard, because, according to their logic, string truncation is unsafe, while buffer overflows are somehow safer, for some strange reason. I've seen discussion like that, unfortunately I didn't keep the link, so that you can laugh. :) And, of course, strncat is entirely inconsistent with strncpy:

- strncat always ensures there's a null terminator in the destination, while strncpy doesn't guarantee it.
- strncat doesn't fill the rest of the buffer with nulls, when there's leftover space, while strncpy does.
- strncat's size parameter must be the maximum number of character to add to the destination buffer, minus the null character (so dest must have space for strlen(dest)+size+1 bytes), while strncpy's size parameter is the size of destination buffer.

Thanks to things like that it's mindblowingly difficult to learn how to write correct code, that isn't vulnerable to buffer overflows, using C "strings", and most people don't do it. They think they do, but they always get caught in some of these traps, without even realizing it and that's where almost all of the buffer overrun security exploits come from.

Nikolay

”}”.

I don't know why this argument pops up over and over again. To me it's just the opposite:
I can type "begin" and "end" much faster than the cryptic { and } (on my german keyboard).
I use all 10 fingers for typing and each special character is an interruption in my coding flow..

Also, as I already often said:
Program code is *written* only once but maybe *read* very often. I prefer readable code even if it takes a millisecond longer to type (which is not the case for me!)

Also IF statements require the extra “then” keyword etc.

Same argumentation here.
I don't bother to type just another (ASCII) word.
Before I can think about a delay it is typed already...

As for indentation. At least with real TAB character indentation, you

can configure the width of a TAB as a user configurable parameter without affecting the source code. With space indentation you are stuck with whatever the original author did.

That does not help me as I use an indentation scheme that not only relys on TABs.
I always indent the begin (and end) of a block together with the block:

if true then
    begin
    DoSomething;
    end;

This way the indentation always looks similar
independent from whether you have begin/end or not:

if true then
    DoSomething;

Some people indent the code lines only:

if true then
begin
    DoSomething;
end;

And some write the begin on the same line:

if true then begin
    ...
end;

You cannot solve all these cases just by TABs.

Am 2017-05-24 um 14:02 schrieb

I disagree!
You still know the byte(!) length of UTF-8 strings and in many cases you don't need anything more.

If I search for the existence of an ASCII character I can still iterate my string in a for loop:

for i := low(MyString) to high(MyString) do
    begin
    case MyString[i] of
       '!' : do_something;
       'a','A' : do_something_else;
       end; // of case
    end;

Works perfectly on UTF-8 strings.

And if it's coming to the number of glyphs in a string you will have a hard time anyway because of diacrytics etc.

But I very seldom need the exact number of displayed glyphs. And for these cases there are powerfull functions available in Free Pascal to handle them.

Karoly Balogh (Charlie/SGR) wrote

OK, this is also beautiful, thanks again. :) BSDs seem to have strlcpy() tho', which works around both defects mentioned here, but that's non standard obviously, because who needs standard functions which make

sense.

:)

Yes, and there is still a lot of very old C code used in programs and libraries that was written with strcpy and I doubt that someone will change all theses occurences at any time.
Why should it be changed?
It works! ;-)

Then why hasn't it been added to the C language definition yet?

At Turbo Pascal times I also added routines for variable length arrays but because of getmem etc. I lost range checking etc. It was an ugly hack (nevertheless the only way to handle such arrays at that time).

Now with dynamic arrays I am so much happier.

Why weren't such things added to C decades ago?
Strange.

Jürgen Hestermann wrote

I can type "begin" and "end" much faster than the cryptic { and } (on my german keyboard). I use all 10 fingers for typing and each special character is an interruption in my coding flow..

I use a custom Dvorak keyboard layout. I used to use Programmer Dvorak, where the symbols are where the number row normally is - but don't require a SHIFT. So { would be a single keypress.

http://www.kaufmann.no/roland/dvorak/

These days I use a custom Dvorak on a Ergodox keyboard. All my most used symbols are on the 2nd layer. I use my left thumb to temporarily switch layers, and then the rest of my left hand fingers to type the symbol. No typing ://github.com/graemeg/qmk_firmware/tree/gg_dvorak/keyboards/ergodox/keymaps/gg_dvorak

But I get what you are saying. Most people can’t type symbols or numbers as fast as the normal alphabet.

I’ve been working with Michael van Canneyt for the last two years, and he indents like that too. It drove me nuts in the beginning, but kinda got used to it - though I never indent like that. Your last sentence at least explains why one would want to do that.

You cannot solve all these cases just by TABs.

These days I don’t care about code formatting at all - while I code. I just type. Then on occasion I press Alt+S which triggers Jedi Code Formatter which formats my current unit as it should be. I have different formatting styles for different clients. It’s a huge time saver! If only Lazarus IDE had a faster way of switch between formatting styles (would be nice if it was integrated with Project Groups). At the moment I have bash scripts that flip between them.

Regards,
Graeme

In our previous episode, said:

That, and the fact that while (a=b){} goes through undetected. In general it relies too much on symbols !^%&===?{}, etc etc. While that might be my Pascal bias, I program C very regularly for over 10 years now, and I haven't gotten used to it.

C also shares some of (IMHO) Pascal's failings, like not distinguishing procedural end from other blocks "end" and complex blockstructure. (different syntax for 1 and multi line blocks).

Graeme Geldenhuys wrote

Once again, read how the Git project deals with it. That workflow could suite FPC quite well.

You never developed a real world compiler and you have no real insight into fpc development so you cannot know about this.

Who tests and signs? Our testing facilities cannot test more than a few (1, 2 maybe 3) branches nightly as we use build farms used also by other people. Further we test also on slow system, where one run takes >1h. We have already >150 regression test runs per night with different parameters, on difference architectures etc. This cannot be extended. Everything not in trunk (or master/) fixes is not seriously tested and cannot seriously be tested, due to lacking resources. So feature branches make only sense for big changes (as we do already with svn).

Or tests the "crowd" which makes OSS so powerful and everything is reviewed by dozens of people? Looking at the problems FPC 3.0.2 has, people even didn't test release candidates seriously. And some branch for a single feature? May I laugh?

Florian Klämpfl wrote

You never developed a real world compiler and you have no real insight into fpc development so you cannot know about this.

As a technical consultant for many clients I have seen a boat load of projects from banking to online trading to educational etc. I'm sorry to bust your bubble, but how different can compiler development be. I'm not talking about the recursive build process, I'm talking about bug fixes and implementing new features.

Who tests and signs? Our testing facilities cannot test more than a few (1, 2 maybe 3) branches nightly as we use build farms used also

Like the Git project, you can merge all new work into a testing branch. That could be what "trunk" is now. Once features have been tested by FPC core members or community - using that trunk branch, those signed off features can be merged into a more stable development branch... lets call it "develop" (or in terms of the Git project, call in "next"). The "next" branch will always be more stable that "trunk". The "next" branch is also the one the next release (hence the name) will be based forked from.

If you haven't found the Git project documentation on this workflow, I'll find it for you and post the URL.

I think actually the 'git help workflows' command lists that same information.

Regards,
Graeme

So no compiler? ...

I'm sorry to bust your bubble, but how different can compiler development be.

Apparently it is:

Graeme Geldenhuys wrote

I don't know compiler design or how it works internally. So contributing in that area is out of my scope.

:)

If you haven't found the Git project documentation on this workflow, I'll find it for you and post the URL.

The workflow will not change. If the tool does not fit the workflow, it is the wrong tool. Period.

In our previous episode, Florian Kl?mpfl said:

> If you haven't found the Git project documentation on this workflow, I'll find it for you and post > the URL. The workflow will not change. If the tool does not fit the workflow, it is the wrong tool. Period.

Even if we will change workflow more GIT like in time, the required leap of faith and transition is too large.

I think the Git advocatists should focus more on a workable model for a transition and not some ideal in the far future.

Even a limited change is already a massive operation, let's keep it managable.

What if you have backups, distributed all over the globe? Oh wait, a meteorite hits Earth and wipes out all life. Everything is now a pile of rubble. Oh the backups where all stored on the same planet and now they are gone. :)

Nikolay

Florian Klämpfl wrote

> I'm sorry to bust your bubble, but how different can compiler > development be. Apparently it is:

Then why are you still talking to me.

I have my doubts that it can be _that_ different. To quote Marco "I see to proof to make me think otherwise".

The workflow will not change. If the tool does not fit the workflow, it is the wrong tool. Period.

Yes, habits (good or bad) are a hard thing to break. In that case, please enjoy your project further with SubVersion. Until you actually use a project with Git (not git-svn), we might talk again. But like you, I'm not holding my breath. ;-)

Regards,
Graeme

Marco van de Voort wrote

Even a limited change is already a massive operation, let's keep it managable.

So how large is the FPC team really? I'm talking about active developers on a day-to-day basis who have commit access to Trunk.

Oh wait, I can answer that very accurately myself... using git.

$ cd /data/devel/fpc-3.1.1/src
[src (master)]$ git shortlog -s -n --since=4.months 191 Michael Van Canneyt
147 Mattias Gaertner
140 nickysn
83 svenbarth
73 Florian Klaempfl
62 pierre
52 Joost van der Sluis
39 maciej
30 karoly
26 Marco van de Voort
23 Jonas Maebe
22 yury
7 lacak
5 marcus
3 Sergei Gorelkin
2 hajny

So that's 16 developers - a nice size, but also not a large team (say compared to the KDE project that moved from SubVersion to Git, or LLVM seeing as that was mentioned earlier). The amount of commits are also not huge - so they most likely have a day job. ;-)

And the two developers with the most commits (by a large margin) work primarily in the RTL and FCL. That's development work like any other project I have worked on. Nothing special or "rocket science" about that (sorry Florian).

As for the 3rd person "nickysn"... I see he/she actually worked on the compiler/* tree. How do I know this?

   $ git log --name-only --oneline --since=2.months --author=nickysn

Randomly picking some other authors, it seems most work is primarily in the RTL and FCL. A few small exceptions like Sven and Florian who mostly work in the compiler tree.

So this definitely doesn't convince me that compiler development is so different to other projects. And definitely doesn't rule out that Git couldn't work, or that an improved workflow couldn't be applied (freeing up time in the long run).

But I get in now. You guys are set in your ways - good or bad, and currently not willing to change. So I'll leave ,
Graeme

In our previous episode, Graeme Geldenhuys said:

...

So this definitely doesn't convince me that compiler development is so different to other projects. And definitely doesn't rule out that Git couldn't work, or that an improved workflow couldn't be applied (freeing up time in the long run).

You are mixing up your replies. I only excluded the Linux kernel as model (since it was written to their workflow). BSD afaik still uses GIT, and like LLVM experiments but haven't moved to GIT.

Actually infrequent committers make the change harder, since they spend a higher percentage of their freetime on the move :-)

Actually, that's me and I'm surprised I'm topping the list. Maybe that's because I'm still using plain old subversion, instead of git-svn, which forces me to commit my changes, instead of keeping them in a half-baked state, in a local branch of a local repository. :) Maybe it's also worth mentioning that I actually dislike git. Previously, I didn't care, but now I contribute to some other projects, which use git and I'm constantly annoyed by the extra complexity and having the source control system stand in my way and preventing me from doing actual work.

The problem is: the current FPC development model is working fine. There's nothing wrong with it. You're pushing git as a solution to a problem that doesn't exist and promising we'll see the light, as soon as we apply your solution.

But I get in now. You guys are set in your ways - good or bad, and currently not willing to change. So I'll leave course, we are. There's nothing wrong with that. We have a solution

that works and that's fine. Why do you want to persuade people to use git so much? Does it bother you so much that people are using a tool that you aren't using?

Here's an analogy of how the git bible-thumping looks to a subversion user:

Are you driving a car? I don't know whether you do or not, but let's suppose you are, for the sake of argument. Why don't you switch to a truck? It has many advantages over the car - everything you need to carry with a car, you can carry with the truck. Sure, it takes more time to learn how to drive it and to acquire license for it, but it's a worthy skill, since it'll make you a better driver. And as soon as you need to move a lot of stuff, you'll love the fact that you learned how to drive it and bought it. And sooner or later, it happens to everyone to have to move a lot of stuff. So, I don't understand why people are still using cars. They make no sense - they are too small and therefore, useless. I simply can't see why anyone would want something more lightweight. But you're living in a big, crowded city, with lots of small streets and you're not really carrying all that much with your car, you're only using it to go to work, so you think you don't need a truck? But these advantages only exist in the minds of the car owners - you can drive a truck in the city as well in more than 99% of the streets, where you can drive your car. And in traffic jams, it's only going to be 1-2% slower. And, if you're driving in an area, where it's not appropriate to drive a truck, but you can drive a car, this is a sure signal that you're doing driving wrong. If you have to drive small city streets it's better to leave your truck at home and walk instead. Cities are for walking, not for driving. But you like the option of driving 3 or 4 people? That's yet another misconception car drivers often have, which is a sure symptom they've never owned a truck and their mind works in an car-focused, truck-unaware, unenlightened way. In fact, you can easily fit a lot more people in the truck. You just put benches in the cargo area.

I hope you get the idea ;-)

Nikolay

Nikolay Nikolov wrote

Here's an analogy of how the git bible-thumping looks to a subversion user:

[...]

In fact, you can easily fit a lot more people in the truck. You just put benches in the cargo area.

Great comparison :)

I hope you get the idea ;-)

I fear he will not.

Graeme Geldenhuys wrote

But I get in now. You guys are set in your ways - good or bad, and currently not willing to change. So I'll leave hope I might quote you in a few weeks/months/years :)

Florian Klämpfl wrote

The workflow will not change. If the tool does not fit the workflow, it is the wrong tool. Period.

I'm not an apostle of Git, nevertheless, your statement is wrong.

Workflows are designed according with the tools you had when you designed it. Sometimes you improve your workflow as you improve your knowledge of tools. And sometimes you create new tools to improve your workflow.

But sometimes other people create a new tools that improves the system but requires a dramatic change of workflow for better. I know Changing of mindset is never easy, but the attitude of "I won't change my workflow" closes the doors to any improvement.

Many projects are using Git, we are not talking about early adopters or isnewisbetter guys. It has been tested in real world for several year, and may projects are moving to it. So I would give it a second chance. I'm doing so, in spite I'm not exactly a young boy and early adopter, I can see some advantages in git easy branching and merging.

Evaluate git and workflows again as for the first time, as if it were the first time you have heard about it. Forget Graeme Geldenhuys, sometimes he says things with manners that.... well, sometimes is looks like seducing people is not among his virtues but the other way around ;-), Take a new fresh look to Git.

To avoid that people get the impression we do not know what we are doing (or not doing).

To close this for now and ever: I am using hg at least since 2008 and git at least since 2011 when it got popular on windows (both natively), hg daily for several periods. And overall the experience collected during this is for sure a reason (besides others!) why using a dvcs for FPC development is not a good thing.

And let me also state when we can open is discussion again:

Either
- FPC gets that much "third party" contributions that managing and merging them gets a problem of the scm, we are light years away from this point though. or
- Somebody pops up who has the time and motivation to push and to do(!) the migration. This does not mean to do a half baked conversion of the fpc-svn but the whole process, e.g. starting with a wiki page collecting all issues and working out solutions, adapting all scripts for release building etc., fixing all snapshot and regression test machines and it ends up with helping the low traffic contributors to get their work committed (and pushed!). This is at least one month of work I (and probably nobody else) can and want to spent.

Florian Klämpfl wrote

This is at least one month of work I (and probably nobody else) can and want to spent.

And some how I believe that will never happen (or be allowed) even if I (or somebody else) decide to donate a month of our time. I fear the resistance will outweigh the dedication to accomplish this task. This was made abundantly clear to me now.

Regards,
Graeme

In our previous episode, Santiago A. said:

I've done so every time the discussion looks up. I also have some DVCS experience with Mercurial, and I still don't see it.

Indeed, it depends on the person who does it. It requires knowledge about the specific workflow requirements of a compiler project. And that this is not easy is proven by the fact that gcc as well as llvm still use svn as canonical repository. They probably have a lot more man power than FPC.

2017-05-24 14:12 GMT+02:00 Karoly Balogh (Charlie/SGR) :

Disclaimer for the remainder of the mail: I've seen Florian's mail that he currently sees no need to move FPC development to Git, nevertheless Charlie's mail was too interesting and constructive not to respond to it :)

The integration of Pull Requests into upstream SVN would indeed need to be automated as much as possible (I see where Marco is coming from). In essence those people that currently are allowed to commit to SVN trunk would be allowed to send a Pull Request to the integration system (which would automatically do the merge, build and run the testsuite and commit it to master if successful). If an external developer would want to see something committed she'd need to send a Pull Request to one of the Core developers or there would be some general catch all mechanism in place and some Core developer could just pick up any pending external Pull Requests and sent it on to the integration system if deemed worthy of inclusion.

Of course the biggest obstacle is the building and running of the testsuite. As Florian wrote in one of his other mails we're partially/primarily relying on build farms that are shared with other users and on some systems the testsuite run takes long (e.g. on my PowerBook it takes around an hour). So maybe the Pull Requests for the integration system could be designed in such a way that only a subset of the supported targets can be requested for build and testsuite runs or maybe only a fullcycle is done together with a full build of only one target all depending on whatever the Pull Request specifies. There would of course be the possibility that this would break some target that isn't in the test subset, but let's be honest: that currently happens as well :P

With the more automated verifications regarding the integrity of the SVN the better. But Marco was right on the point, that this needs a very very carefully designed plan and process, to not screw up the upstream SVN. Maybe what LLVM and GCC has in place can serve as a starting point.

Qt for example has a similar process (even though they don't have a SVN master repository anymore like LLVM and GCC do), see here: http://wiki.qt.io/Qt_Contribution_Guidelines

I agree that this could be solved with some engineering if enough willpower and time (and insight into FPC's development process) is available.

Regards,
Sven

Hi,

Sven Barth wrote

nevertheless Charlie's mail was too interesting and constructive not to respond to it :)

Awww, you, stop it... *blushes* :D

Of course the biggest obstacle is the building and running of the testsuite.

Well. Build breakages are daily occurence with obvious "this could have never built" mistakes, or new packages get committed which don't build for any platform, etc. Even large patches, with little care and "worksforme" excuse. So even in the current system we run the testsuite *AFTER* the commits are already made. And lot of the experimental development happens in directly trunk. So this reaction of "omg, what happens to the testsuite runs" I feel a bit... Yes. :)

And I'm guilty as well, make no mistake. :) But actually this leads us to another problem, that now all commits are equal, even if someone touches an uncritical/new package or some x86 codegenerator or a critical part of the RTL. If the later breaks, could cause problems for everyone years down the line, while a package will almost certainly only affect some people. Which means different developers work in the same repo with different quality/criticality standards...

Indeed. I think we already have an informal list of "Tier 1" systems anyway, which is more or less Windows, Linux-i386/x86_64 and Darwin. I think (almost?) everyone uses these as development hosts, even if he works on some other system in the end. But breakages in these affect quasi everyone immediately. The rest is "irrelevant". (Disclaimer: I mostly work on other systems, so I can claim this. ;))

There would of course be the possibility that this would break some target that isn't in the test subset, but let's be honest: that currently happens as well :P

Indeed.

To be honest, I don't see a lot of difference to a Pull request or a diff submitted via Mantis. A core developer has to handle both, and sign it off. From then on it's his responsibility to handle the patch during its lifetime, and revert or fix it, if breaks the build and next days' testsuite runs. It's actually pretty much irrelevant if the change got into trunk via a manual diff/patch/commit, or someone integrated a pull request. What I meant is some automatic process, which makes sure you have a linear history suitable for an SVN upstream commit, etc.

I agree that this could be solved with some engineering if enough willpower and time (and insight into FPC's development process) is available.

Indeed. Some of these "rules" or process ideas sound like an improvement even if Git is not in the picture. :)

Charlie

In our previous episode, Florian Kl?mpfl said:

So does FreeBSD, (though IIRC they also use Perforce internally), so even it is not pinacle of OS kernel development either :-)

In our previous episode, Sven Barth via fpc-other said:

Of course the biggest obstacle is the building and running of the testsuite.

I think running the testsuite is a waste of time and cycles for anything outside compiler/ and rtl/. And even for half of the RTL.

2017-05-25 15:20 GMT+02:00 Karoly Balogh (Charlie/SGR) :

I'm aware that the current situation isn't all roses and such (see the typo you fixed a few days ago: that was me removing a "virtual" without its semicolon directly before the commit even though I had already successfully built the compiler previously). So if we had an automated process to catch such things at least on the Tier 1 systems you mentioned below that would go a long way already I'd say and - as you wrote as well - completely independant of SVN or Git.

Maybe such a hypothesized integration system would be a bit more rigorous depending on what files were changed? E.g. full build with fullcycle plus testsuite run on Tier 1 targets if anything in compiler and rtl was changed and only a full build if merely something in packages was touched.

I agree.

Maybe we could try at least part of it:
Step 1: have an official FPC trunk Git mirror on our own server with a mirror/fork of it on GitHub (were those license troubles regarding GPL and Co I mentioned some months ago solved, btw?) and accept Pull Requests on the GitHub mirror (those would of course need to be processed by core devs willing to use Git :P )
Step 2: adjust the Git repo on our own server so that it can react to Pull Requests from authorized developers (aka us Core devs) as well and have it do the integration stuff (which of course would require writing or finding such a system which would be a whole topic in and on itself) all the while the development process can continue with SVN as well (without the integration shenigans)
Of course Step 1 would require us to do a conversion from SVN to Git of at least trunk and to make sure that all revisions that need to be there are indeed there (e.g. if Graeme's statement is true that Git ignores commits that only have property changes).

This is of course a rather simplified view of all this and many problems along the way would need to be solved.

Regards,
Sven

2017-05-25 15:34 GMT+02:00 Marco van de Voort :

I essentially agree which is why I wrote in my message to Charlie a moment ago that the integration system could differentiate here based on what files were changed.
Though maybe partial testsuite runs would be useful as well, e.g. if something changed in the rtti unit (which is in the rtl-objpas package) the tests for that unit/package should at least be run. This of course would require a few more adjustments to the testsuite, but it wouldn't be an unsolveable problem.

Regards,
Sven

Hi,

Στις 2017-05-25 16:53, Sven Barth via fpc-other έγραψε:

< snip >

who needs github when you have gogs ( https://gogs.io/ ) ?

It's a 5 minute setup and is very solid .

regards,

Hi,

Actually, the irony is strong with this one, as Gogs hosts their own source on Github. :) But it's actually looks like a cool interface if one needs self-hosted "Github", I like it, thanks for this.

Charlie

Hi,

Στις 2017-05-25 16:53, Sven Barth via fpc-other έγραψε:

< snip >

May I ask currently for "Tier 1" how many physical systems fpc team have available for the automated test suite ?

regards,

Hi,

Στις 2017-05-25 17:13, Karoly Balogh (Charlie/SGR) έγραψε:

Hi, On Thu, 25 May 2017, Dimitrios Chr. Ioannidis via fpc-other wrote:

< snip >

GitHub is those days what sourceforge was 5 -8 years ago ;) .

For the company I work ( small team ) and for my personal projects Gogs solved the usual "painfull" IT tasks reg. scm's .

regards,

2017-05-25 16:13 GMT+02:00 Karoly Balogh (Charlie/SGR) :

It looks nice indeed and we *could* use it to have the main instance for pull requests be our own server instead of GitHub, but we'd need to evaluate if we could restrict authorization as much as we'd need it (e.g. pull requests of non-authorized users would need to be addressed by core devs, authorized users might either have full access or restricted access (e.g. Matthias Gaertner could be restricted to packages/fcl-passrc and packages/pas2js, so pull requests only changing files there could go through as for ordinary core devs while pull requests modifying other directories would need to be handled by a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server...

Regards,
Sven

Sven Barth wrote

a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server...

Gitolite is brilliant at directory level, file level, branch level, site level permissions, private branches support and more. It's very flexible and uses git to configure itself - so config changes and new repo setups can be done remotely, and as soon as you do the push the server is updated and repos are created.

http://gitolite.com/gitolite/

It is also very simple to install and set up. Also a under 5 minute job.

ps:
I just thought I would point out that a web interface (Github, Gogs and others) are not the only way to do pull requests. In fact, pull requests via a email message is much more informative and easier for other person to review. This is built into git.

For more information see:

      $ git help request-pull
   So you guys might want a daemon that scans the fpc-devel and
   fpc-users mailing lists too. That's if you want to cover all
   bases.

Regards,
Graeme

Hi,
Στις 2017-05-25 17:34, Sven Barth via fpc-other έγραψε:

< snip >

a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server...

Ok just setup gogs for testbed / evaluation at
https://fpc-scm.nephelae.eu/ .

Anyone interested for admin credentials for evaluation just email me privately .

regards,

Hi,

Στις 2017-05-25 18:24, Dimitrios Chr. Ioannidis via fpc-other έγραψε:

This machine is a private test VPS in a DataCenter in Germany, so feel free to do whatever you want .

regards,

2017-05-25 17:24 GMT+02:00 Dimitrios Chr. Ioannidis via fpc-other :

I appreciate the gesture, but if I'd want to evaluate it I'd do this on my own system.

Regards,
Sven

Hi,

Στις 2017-05-26 13:55, Sven Barth via fpc-other έγραψε:

2017-05-25 17:24 GMT+02:00 Dimitrios Chr. Ioannidis via fpc-other :

< snip >

I realize that yesterday I was little too spontaneous. I don't want to look that I'm pushing in any direction .

Preferences noted ;)

regrads,