Darian Miller

FWIW, there is apparently an effort: https://www.crossvcl.com/

Check out

That's probably less than 30 days for me. 🙂

I stay away from rebasing. It just feels like a dirty approach. Perhaps I just need to do it more often but I probably won't use it unless I'm forced to. I started out with a 'sneaker net' version control system as we didn't have a network. A couple times per day I would copy a few source files to a floppy, walk down the hall and hand it to the one other developer to copy to his machine (or he did it with me.) We would merge changes manually. (We split up tasks to specifically keep merging to a minimum.) After months of this, we finally put in a network and shared files from a single location and used MultiEdit to modify the source. It managed the read only lock on the file to prevent two people from accessing the same file. We kept up with file locks with VSS for about a decade and then moved to SVN for the next decade. Large project, built over 20 years with millions lines of source with 10 or more Delphi developers each committing multiple times per day. We kept merges to an absoulte minimum and were quite successful. For a long time, I directly managed the workflow and kept the merging to a minimum based on task assignment. I think it's kinda rediculous to even contemplate 5 people editing the same DFM and attempting to merge UI changes (but sometimes it did have to happen.) Most UI conflicts were basically minimized outside of the VCS. I'll follow whatever the workflow is of the next company, and may hit you up on advice on rebasing if they follow that approach!

+1 for Videos as they can play while you ware working on something else. My favorite part about youtube is the playback speed feature. I normally crank it up to 2, but scale back down on occasion as needed. Alister Christie is a good example of having to scale it back. He articulates his words pretty quickly so at a speed of 2 it's difficult to understand so he gets 1.5. After my kids showed me this feature, I nearly always use it now. I have a hard time watching someone speak now at a normal speed.

Ask Dave Farley - that's his quote (and assumedly a large factor in selling his CI/CD training services.) I said 'apparently' there has been studies to prove it. I took Dave at his word, but also hedged my statement as I foretold a response. If you are making money doing what you are doing, then you are obviously doing something right. If you want to make more, then perhaps some well defined tweaking will improve the situation - but as we have all seen time and time again, new managers trying to dramatically and quickly change workflows typically end up costing a lot of producitivty and rarely succeed. In the recent developer interview process, I was quizzed on Chesterton's Fence and software development. They were happy with my response. I do not advocate for wholesale changes for a working system. If there are ways to improve it, and there also exists valid business reasons to enact those changes, then they should be considered. In this thread, if one is struggling with the real costs of too many branches, or not enough branches, then I suggest you watch Dave's videos and see what insight he has. He's a pretty successful person in this area. You reduce the need for branches by introducing Feature Toggles, Dark Launching, and Branching by Abstraction, but you don't necessarily eliminate them.

As the videos I posted conclude, apparently it has been proven that software is developed more quickly and more robust with CI/CD techniques which involve few (if any) short-lived branches. I tend to agree with that concept. Every situation is different and success is measured in different ways. I know what has worked well for me and what has not. I leveraged that knowledge to help me retire at a fairly young age. But I'm heading back to work soon after a few years of inactivity as I simply enjoy to code and retirement is somewhat boring (especially in an extended pandemic which doesn't seem to want to end.) And the place I'm going to apparently uses branches heavily, so that's what I'll do. It obviously works for them as they have enviable market share and have been making software for 30+ years. It's difficult to argue with success. So whatever is working well for you, certainly keep doing that but there's nothing wrong with thinking about improvements. It would be foolish to change something that's working solely based on some video or forum message.

Which is why I said they become more painful as time progresses. Managing branches 'properly' typically becomes increasingly difficult as the number of branches increase as the change scope creeps up and conflicts quickly mulitply. Branches typically defer and increase the pain of merging. It's best not to branch at all unless you can guarantee isolation, but if you can do that, then you can use other methods to stick to the mainline.

I suggest you be careful managing 'many branches'. Merges become much more painful as time progresses. Choosing the appropriate branching method heavily depends on the type of product and how it's deployed to the users (and how many distinct active versions you maintain.) Since you are a single dev team - you get to pick the least painful, most productive way to maintain your software. Here's another reading source for you: https://trunkbaseddevelopment.com/ There is no 'perfect' way of doing things. One of my mantras has long been "Progress, Not Perfection" If you slowly get better over time, your cumulative progress will add up rather quickly. This counters the real fact that "change is painful" On my team, we went years avoiding pain and it just made things much worse. So it seems like you are on the right path - keep poking away and things will get better.

For me, I sometimes like to watch coding videos. This guy is pretty good. He likes stating controversial statements as click-bait, but nothing is written in stone. There are exceptions for everything.

From Dave Farley:

Same here.. which is why I followed-up with a message to David today.

I was thinking about this thread today and was curious - what is your different way to solve the initialization order problem?

You'll want to read through this thread:

Thanks. I'm glad someone uses it besides me! 😃 And if anyone has other info to add to the page, just let me know.

You may want to review this one as it has some recent changes to PdfiumLib https://github.com/TextEditorPro/TPDFiumControl

Why don't you extract the email addresses and process them individually? Also look at: https://github.com/Xor-el/EmailValidationPascal

If you are using 10.4.1 or 10.4.2 are you migrating code to utilize custom managed records or are there some blockers preventing common usage? I know the initial release with 10.4 had some major issues with their usage but 10.4.1 had addressed a number of errors. After some searching on the Quality Portal, this related issue is still open: https://quality.embarcadero.com/browse/RSP-34165 Managed records are sometimes not initialized to 0

Sure, if that was easy they would have done that part already. 😉

No, not really except you simply have another version of Delphi to support, which is typically another VM to keep around. It would be nice to delete the old Delphi VM and simply use the latest version of RAD Studio to support all of your projects, including the ancient ones. I know that's a big ask but in this case, it's not a major change to allow that to happen.

And frequently it happens to be true.

I think that number is probably underestimated as many of the XP machines aren't connecting to the internet. Just busy running 24x7 on a factory floor somewhere, in a kiosk, or cash register. (Not to mention all the Windows XP still in use by government and military)

I've been keeping a list of links for each version since 10.3 on that GitHub wiki (of course, I mean to go back to versions prior but never seem to have the time, nor desire as it takes a decent amount of effort.) There are always issues with a release but a few years after the fact you can never remember what workarounds were needed and you often simply have to relearn them the hard way. For example, if you inherit a project to support that is based on 10.3, it would be nice to know what the glaring issues were with that particular version. Always installing hotfixes solves many issues with a major release, but not all of them. So with RS11, I included a new section "Some reported new version issues" so I have a little insight to what issues were brewing upon release. It's certainly not the best option, but I'm open to assist with a better implementation. I know that this has to be a huge problem for Embarcadero and the Delphi community as a whole. There are many thousands of developers stuck at an older version for various reasons. If we could get some insight into those reasons over time, and build some assurance that the latest version finally addresses their issues, then perhaps many more can upgrade to the latest - which should help Embarcadero and the rest of us as well. I know a huge number are stuck on versions prior to 2009. But there are also various developers stuck at XE2, 10.2, 10.3... RAD Studio 11 should end up being a very strong version. Other than a rather funky behaving non-dockable floating form designer (which I certainly hope gets more work), I don't know of any really strong reasons for all those on 10.1? or later not to upgrade except, of course, for the obvious issues with Third Party Components. (Where the pain is lessened if you adhere to the law "Thou shall not buy a Third Party Component without full source code.") If you are reading this and cannot upgrade - what specifically prevents you from upgrading to RAD Studio 11? Maybe we should start a new thread for that...

Once you get it installed, it does seem very nice. The non-dockable floating form designer is a bit funky but I do not resort to using that very often. There are reported compatibility issues with TNumberBox and TScrollBox. Also watch for possible unintentional image resizing iin VirtualImageList if using the HighDPI designer. I started a list of things to look out for: https://github.com/ideasawakened/DelphiKB/wiki/D28.ALEXANDRIA.11.0.0.0

I get E2099 in 10.4.2 at compile time so it's not a new issue. In RS11 I get integer overflow at runtime on the last one so there is some change in default behavior since 10.4.2