David Heffernan

This is a good point. Perhaps some settings suit a process with no branches. But This can't be right. You can't ever "prove" such a statement. There's never going to be a one size fits all approach. We all have to do what works for us, and be prepared to entertain new ideas and approaches.

Branch management requires skill but it's perfectly possible. You just need to know how to do it.

It's not so much how many branches. It's how long they live and how regularly changes from the develop branch get pulled into them. The other issue that can bite is when you have multiple branches working on the same area of code, for obvious reasons. But I don't think you should be afraid of having many feature branches so long as they are managed properly.

Delphi IDE integration for vcs isn't very good. I'd use another tool for that.

That's right. Which is essentially what the example in my comment was meant to demonstrate.

This question is basically like asking why TButton(ListBox) fails when ListBox is a TListBox. That's directly analagous to your cast.

I don't think you understand what we are saying. On a feature branch you develop a new feature that hasn't yet been released. So if there is a bug in code that has been released it doesn't clash with your new feature, because the feature is new. So the scenario you describe basically doesn't arise. You asked for advice, and we all have experience of this. You don't. Which is why you asked. Just a suggestion. Perhaps our experience means something? Or perhaps I don't understand how you develop. Perhaps you really do rewrite your entire code base regularly.

I don't think so. If the bug is in the code for the new feature then you don't need to push it to the release branch because this new feature hasn't been released. Of course you will sometimes be working on a feature that involves modifying existing code, and those modifications clash with a bug fix for released code. But if there is a clash then of course you have to fix it on the main dev branch, and then work out how to push that to any release/feature branches resolving conflicts. No workflow can avoid that. I'm sure other people can chip in, but in my experience, the vast majority of bug fixes can be resolved and then pushed to release branches without conflicts needing to be resolved.

Not really, the vcs does the work. You fix the bug once and then push it onto whichever branches also need the fix. Irrespective of the workflow you are going to do the fix once, commit it, and then use the vcs to propagate that fix to wherever you choose.

These tools are really useful, but they aren't a substitute for understanding the workflow.

I don't really understand how tools can support specific workflows. Aren't workflows just conventions that you put on top of the vcs? I mean, I'm sure that I can do git flow, gitlab flow, github flow etc. with any tool.

Fix it in development branch, and then merge on to feature branch and release branch,

Read up on git submodules properly, and read about the potential pitfalls. Just like svn externals they sound compelling but you can easily get into a bind with them.

This works fine. The key point is to keep separate branches for development and releases.

I don't think it matters how many developers there are. That doesn't change anything. Even with one developer you still need to maintain separate branches for current development and historical maintained releases. I work exactly the same way on my solo projects as I do on my collab projects. I strongly recommend reading up on this subject, you'll get a much better idea than this sort of threaded discussion. Here is a great place to come ask questions once you've read up the subject but I wouldn't recommend starting like this.

This is pretty simple with git submodules and svn externals. For svn externals you specify the commit that you want to reference, and so when you create a release branch, that commit is captured there. If you update the external reference on the development branch, that won't change anything in the release branch. I believe that git submodules work in the same way, they are a reference to a specific commit in a repo.

That's very risky for release branches. Release branches are typically meant for bug fixes. Updating shared libraries as you do is likely to lead to new bugs being introduced to your release branches which are supposed to have a reducing bug count!

Thus isn't how I do it. I have a development branch. New features and bug fixes go there first. Now, if they are anything other than completely trivial they will be developed on feature branches and then merged back to the development branch. Then whenever you do a release you branch off a release branch. And then you choose which commits from the development branch need to be merged on to the release branch or branches. You don't implement anything twice, it's just merges. Obviously sometimes there are conflicts to deal with. You can also buy books that go into this in detail.

The former must be used to create the main form. Otherwise there's no need and you can just call the constructor. That's what I do. Use the Application method for the main form and call constructors directly otherwise. The other difference in these two snippets is the second one has no owner, but the former is owned by Application.

These aren't sprints. Those are a term used in scrum. You can read about that to learn what they are. The simple answer is that you need to use branches. Every time you make a release, create a branch for that release. All bug fixes are made on trunk and then merged onto whichever release branches are supported. This is much simpler and much safer than your current approach.

All I said, and you can go check, is that it is sometimes desirable to distinguish null from empty.

Can't use the operators that we have in other languages

No. Really not a good suggestion. Please don't tell me that you have nil checks every time you use an object.

Generally you know that the list has been assigned. Usually they are created in the same function above the use, or passed in to the function and known to be assigned, or created in the constructor. So no its quite rare to see code like that.

Only there's no language support for that. Why does C# code ever have those all over the place? Mine doesn't. Is sounds a bit like poorly designed code. Or am I missing something?