Anders Melander

First of all: Get a GUI Git client. I rarely use the command line during my daily work. I came from Svn and found the transition to Git very confusing because the terminology is different and because you're basically working with two repositories (the local and the one on the server) at once. What Git server do you use? A pull request is just a request to merge a branch into another. The "pull" is from the perspective of the target so it's a request that the target pull the supplied changes. I'm guessing the way you work now is something like this: Create a local branch. Work on the files in the branch. Commit changes to the branch. Merge the branch into Master. Push Master to the server. With a pull request you would work like this: Create a branch (either locally or on the server, doesn't matter). Work on the files in the branch. Commit changes to the branch. Push the branch to the server. Create a pull request on the server. Review the pull request on the server (should be done by someone else). Accept or Reject the pull request. Apply the pull request on the server thereby merging the branch into Master. I'm still not sure I understand the problem but I'll try with a solution anyway. Let's say your main project is in the Projects repository and that you have this mapped locally to C:\Project. Your client data is in the Clients repository and you have this mapped to I:\. Within the Projects repository you have a branch for each client and the same for the Clients repository. The Master branch of each repositories contains the changes that are common for all clients and the individual client branches contains the client specific stuff. When you make changes to Master you will have to merge that back into each of the client branches to keep them up to date. You can create a script that automates this task. Now if you make Clients a submodule of Projects then you can make the individual project branches track the corresponding branch in Clients. This means that when you check out a Projects branch then the corresponding Clients branch will automatically be checked out as well so your I:\ data will contain the correct files.

When did you get that message? On package install? I don't have 10.4.1 installed at the moment (tested the uninstaller yesterday and haven't had time to install again) so I can't try myself.

I can't see anything in what you describe that is out of the ordinary. Looks like a pretty standard workflow to me. One thing I would do is make sure that very few people have rights to push to Master or whatever you call your primary branch. Instead use pull requests to merge into Master. This avoids the situation where someone forces a push and rewrite history and then later claim that "git must have messed something up". I'm not sure what to do about your I: drive if you really want to have all the files there at all time, regardless of the branch you're working on. If you're okay with pulling the files for a given branch to I: when you work on that branch, then you could reference you I: repository as a submodule in your main Git project. Then each customer could get their own branch in the I: repository. HTH

I believe this is mentioned in the release notes:

Well that's what I get for actually reading the installation instructions.

I'm positive I didn't get that one. I just now tried running the 10.4.1 uninstaller to see if that dialog would appear. First I get an UAC warning because the uninstaller is unsigned. Then I get this one: And clicking on Yes starts the uninstall so now I have to install again. Damned! Was I meant to just run the 10.4.1 installer and have that perform the uninstall? Here's what the 10.4.1 release notes say: Strictly speaking, the first sentence states that I should uninstall 10.4 and then install 10.4 again, but I'm assuming that wasn't what they meant.

No. It's just very easy to miss. Bad installer UI. The 10.4.1 release notes stated that there would be an option in the 10.4 uninstaller to keep the settings, but I didn't see any.

It depends. If you are sure that your event handlers are thread safe then COINIT_MULTITHREADED is fine. Otherwise change it to COINIT_APARTMENTTHREADED. Well if you code isn't thread safe then anything can happen but I think it's more likely that the missing CoUninitialize is the cause.

I just checked the source: On Windows it's just a wrapper around the Windows SRW lock. https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks

There's no need to post the issues that weren't fixed when we have a list of those that (allegedly) was.

CoInitialize etc. only affects the calling thread. If you access FireDAC from a thread, and you have called CoInitialize on that thread, then any inbound COM will be executed on the main thread (i.e. single threaded apartment a.k.a. apartment threaded). I'm guessing you are only doing outbound COM so the threading model shouldn't matter.

And now demo.exe is running you

https://docs.microsoft.com/en-us/windows/win32/api/objbase/nf-objbase-coinitialize And the documentation for CoInitializeEx states:

Why is that man trying to swallow an invisible shoe?

It's a service application so the COM stuff is presumably done in a thread. The CoInitializeEx/CoUninitialize should be done in the thread. Apart from it being inefficient there's nothing wrong with looping and wrapping the server interaction with local calls to CoInitializeEx/CoUninitialize inside the loop. Outside the loop would be much more efficient of course but it might be a good idea to start again with a fresh, clean COM environment after the server has disconnected the client.

It's probably using CoDisconnectObject

Okay. Let's assume that the problem lies with the client. Apartment threading just means that ingoing COM calls are executed on the main thread. This is like using TThread.Synchronize to ensure that code that isn't thread safe is executed in the context of the main thread. If your code is thread safe or if you are sure that you're not using callbacks (e.g. COM events) then COINIT_MULTITHREADED is probably fine. The missing CoUninitialize will affect the client but assuming that you clear all references to server interfaces on disconnect then I can't see how that would affect the server. So your code logic should go something like this: CoInitializeEx(...); try Server := ConnectToServer; try Server.DoStuffWithServer; finally Server := nil; end; finally CoUninitialize; end;

https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex Anyway, that's on the client and it shouldn't affect the server.

Maybe. Since the OP hasn't really stated what his problem is I can't tell for sure. It sounds like he's asking about adapting Git to his workflow or vice versa, which I think is a topic suitable for SO. It depends on how you phrase your question. Regardless there's a good chance he would be told to ask a proper question if he tried SO - or maybe just downvoted but that's also kinda an answer.

I think you need to post some more code and some more details. Does the OleCheck ever raise an exception? If so how do you handle this exception? Are you sure that you shouldn't be using COINIT_APARTMENTTHREADED instead? Are you sure there's a CoUninitialize for every CoInitializeEx? How does the server disconnect the client? Have you tried debugging the server to determine what it's doing when it "hangs"?

Are you aware what the M in MTBF stands for? And it's not the statisticians that are making these claims we are talking about. It's the companies producing the devices, based on their tests, and it's the people that have the experience to back the claims. And yes, they're "experts". Because they know what they're talking about. Like Wozniak. Unlike Jobs.

I'm doing incremental backup and I rotate media every one or two weeks so it's not that bad. The "other house" is right next to the main building and the cabinet is in my workshop, right next to where I keep the beer, so it's nice to have an excuse to "go file the backup".

What I meant was wear from thermal expansion and contraction. There are lots of other factors to consider but it's kinda pointless to explain in detail when you're up against SDs and Raspberry Pis.

I of course meant that the two should be separate after the backup has been made. Not during. At home I'm doing rotating backups to disk. The disks are stored in a non-fireproof cabinet in another building. I'm betting that both buildings don't burn down (or are towed away by "burglers") at the same time. I live in a thatched house so it's not like I'm fireproof in any way.

What are you on about? There's a difference between a fireproof safe which is primarily a safe and a fireproof safe which is primarily fireproof. Guess which one you should use to protect your backup media against fire? The reason it's "a safe" is that if you're going to build a big steel box then you can just as well put a lock on it and call it a safe. If you are afraid that someone are going to steal your safe then close the door but don't lock it. Jeez.