Leaderboard

We've been using SVN for many years now, no complaints. We're however planning to migrate to Git at some point, and are already using it in parallel with SVN in several ways. It is perhaps worth it to note that from a size efficiency perspective Git is much more efficient than SVN. The total size of a git repo + working copy files (which remember, includes all the branches and the entire history of the project locally) is typically quite a bit smaller than an SVN checkout (which only contains the working copy and a copy of the pristine files of a single branch with no history.) So any history investigation or switching between branches requires a connection to the remote SVN server, whereas Git does not require this and allows complete freedom to switch branches, create new ones and interrogate the histories offline. This is extremely useful when you want to do some types of work where a connection to your central version control system is not available. To also note: It is entirely possible to use both version control systems sort of independently at the same time, by making each ignore the other's folders. This has benefits as it starts making the notion of "I have a local repository that I can work against" apart from "the remote" clearer. E.g. commit whatever you like, in as small baby steps as you like against your own development git repo, and once ready commit to your "mainline" SVN repo. Meanwhile when upstream updates happen you get practice in merging and learning how to do this properly using git. Eventually this sets you up to simply swap the step that commits to SVN to pushing to a remote Git repo instead. It is also possible to keep a git repo as part of your SVN repo, if needed/wanted/useful. For example, we use and keep third party sources in a dedicated third party SVN repository, and in several cases for ease of updating to ("pulling in") the latest version of the open source project and to have access to the history of these projects, the path of least resistance was to actually commit the git repo into our Subversion repo. To update then is simply a case of pulling from the repo on github, checking if the update breaks anything and then commiting both the source changes and the changes to the git repo to subversion. (One more addition: Another department actually also use Bazaar, it works well but I'd not recommend it as it's essentially dead in terms of development, and the plan is to eventually migrate that to git too. For clients we use the Tortoise* tools.)

Yes, I have the graph by OS also, but in both situations where the the graph stepped up, it happened with the same OS. So that is not the reason.

@Incus J Using Application.ProcessMessages is not the correct way to test if the GUI is updated in a lengthy process. Put your lengthy operation in a separate thread and add a possibility to cancel it if the GUI detects such a request. Application.ProcessMessages can lead to many hard to find anomalies and program failures.

Maybe the problem is not specifically LiveBindings but trying to do too much on a single mobile screen at the same time. This project uses a number of different livebinded fields: https://community.embarcadero.com/article/16633-deep-dive-field-service-app-template-for-android-and-ios-with-rad-studio-10-2-tokyo

I was always pissed because of the property editor and its incapability to helping the work, so I made this extra filter-box. It has a little discomfort as the Property Editor steals the focus on the first click, I'll check what can I do if I find some time. Also, adding/deleting/storing the predefined filters are unimplemented yet. If someone feels the power to get it done, don't hesitate to apply.

Not necessarily compiler, but RTL/FMX or other frameworks. Yes, there were some changes in compiler that may have influence, but such errors tend to have impact across all platforms. Now, it would be interesting to figure out what exactly is the problem.

Ha, ha, we only release an update when there is nothing new, nothing fixed and absolutely no change in the code 😉 The graph is no proof, but its an indication.

This issue would be a part of the problem: https://quality.embarcadero.com/browse/RSP-21834

ProcessMessages will not work as you may expect in FMX, and definitely not on Android. I suggest avoiding ProcessMessages entirely; then it won't matter which framework or platform you're using. It may be better to describe why you think it's necessary to use it (preferably with example code), because it's likely there are other ways to solve it.

@Eli M. The discussion concerning usability of LiveBindings in production on G+ was quite biased towards unusable. What is your typical data volume i.e. how many tables/fields/rows are bound to how many controls?

That value is as good as any other value. It just has to adhere to the rule that the same value is returned every time when the same input value is supplied.