Lars Fosdal

Nope. As always, we are waiting for Update 1 before we re-evaluate.

Having a fast SSD doesn't hurt, nor does it hurt to have source and output on different drives, but I wish I could get a CPU that had a core that could be clocked really high, since the compilers mostly are single core intensive.

In that case, @David Schwartz, it is probably the DI book, as you speculated above. https://www.amazon.com/Dependency-Injection-Delphi-Nick-Hodges/dp/1941266223 The other approach, using interfaces vs include files- has been touched here: https://stackoverflow.com/questions/1011006/separating-interface-and-implementation-classes-in-delphi and interfaces are discussed in Nick's Coding in Delphi and IIRC in the good old "Delphi in a Nutshell" by Ray Lischner.

I like installers that have proper parameter support - including /Silent

OwnerDraw? Edit: i.e. handle WM_NCPAINT and WM_NCACTIVATE, etc. yourself.

Have you tried using an XML lint tool or validator to check the integrity of the XML file? The MS Word Error is inconclusive to whether it is a structural error, character set error, or logical error in the XML.

Dependency Injection. Works like charm unless you need absolute raw performance. I use that quite a bit for pluggable capabilities. I am not a fan of .inc files at all. I use platform specific units and ifdef the uses statements. I do have a xplatform unit that ifdefs the various implementations - many of who simply raise Exception.Create('Not implemented'); 😛

I am not confused. I am frustrated. I want both. Most of all, I want 64-bit debuggers that understand threads and make it easy and robust to focus debugging on specific threads, and that doesn't suddenly stop breaking on breakpoints or break on "invisible" breakpoints in Indy, or just purely stop responding completely. I'd love to be able to "disable" exception breaks for specific threads and only for those threads. I want the broken HighDPI properly and finally fixed. I want the code generation significantly improved for 64-bit. I want RTL, VCL and FireMonkey to be rock solid and efficient. But - also ... I want Generics constraints for enumerated types so that I can use enumerated type and set type operators. I want proper nullable type support, including the relevant operators. I want ARM support for Windows. I want ARM/Linux support for Raspberry PI. I want the static code analysis capabilities of FixInsight and similar, to be built into the DSP. I want a package manager that really works, unlike GetIt which is just a glorified downloader and installer. I want Swagger support for APIs.

If a column is nullable, it is a good practice (for T-SQL) to use stuff like ISNULL(MyString, '') or ISNULL(MyInt, 0) in queries, particularly if there are totals or min/max operators in the query or view.

The link appears to work for me.

If you avoid this, one of the branches will be left unfixed. You always must fix it in both places. The question really boils down to which model you use.

I guess it is because conceptual explanations tend to look at time starting from the top, going down - while actual systems tend to show recent events on top, going back in time as you move downwards. Ref. email inboxes, Windows Event Viewer, GitKraken, etc 😉 For the graphical view, it also makes sense to have the main branch + longest living branches on the left, since the number of branches varies.

The RFC describes four variant formats, and the MS GUID is variant 2. I am simply wondering if there is another implementation than the MS one available to me in case the MS one is not compatible with IBMs requirements. uses System.SysUtils; var guid: TGuid; sguid: string; begin if CreateGUID(guid) = S_OK then sguid := 'urn:uuid:' + guid.ToString.ToLower;

As long as what you push to the shared repository, compiles 🙂 It is very annoying if teammates commit code that doesn't compile.

Correct. Most UIs for git visualize branches and merges.

They are. GitKraken supports implements the GitFlow convention, simplifying the execution of that workflow.

Ref the chart I posted. That patch or hotfix if you like can be spun off the release branch and committed and merged back into the release branch and the development branch. I am fond of GitKraken here, because it supports GitFlow which simplify doing these things.

They are similar, but not identical it seems - judging by this: https://github.com/stettberger/git-external

Ref. https://nvie.com/posts/a-successful-git-branching-model/ We came from SVN, so we had to rework our mental SVN model for git, but once we learned the mechanisms, none of us miss SVN at all. One of the hurdles was not thinking about master/main as trunk, but as the release branch, and that you did all the work you used to put in SVN trunk, into a develop branch. Feature branches are really, really helpful - but don't let them drag out too long, or you will likely be facing merge conflicts if you are multiple people working in the same repository.

TBH, I don't know for sure since I've never used that feature myself since we always use the same version of the shared code for all our projects. I'd have to read up on sub-modules and externals to find out, but perhaps somebody else here is using this?

As we've touched on before, @Uwe Raabe , the "fun" starts with 3rd party design time components. Maintaining projects that use two different versions of f.x. TMS components is something I really want to avoid if I can.

Pinning a version means that you pull from a specific version instead of the HEAD version (i.e. latest)

We use this model. Works quite well. https://nvie.com/posts/a-successful-git-branching-model/

We do that, but we can do that because our projects are inhouse and closely related, and we have control over the release and upgrade cycles, and we always upgrade all apps to using the latest 3rd party libs. But - if there are 10+ projects that are not really related, they would need repositories of their own, and the shared code would need to have a repository of its own. The question remains whether the shared code should always follow the latest version, or if you pin a version per project and upgrade on need only. The third party libs dependencies will be a challenge here - especially if there is a difference of version of the libs between the projects.

That I did not know. Thank you, Uwe!