81–90 of 90 posts
Earlier quoted context omitted.
Why are you reposting these sentences with additional errrors inserted into them?
i was rephrasing , saying what i understood (thinking i was making it clearer) you are suggesting, i misunderstood the original text , if that is true i blame the original of being obfuscated
Earlier quoted context omitted.
Yes, specifications which could almost certainly be applied with a custom merge drivers or strategy rather than trying to come up with a clever name and hand baking a custom toolchain to do what you can already do with Git
Not all projects use git.
AFAIR, LMDB is very buggy. There was one person who showed that and maintained fork of LMDB with many bugs fixed, but he is very opinionated and think that world outside Russia is "evil" and forbid to use his fork for evil... Oh, license was changed to Apache 2.0! But still github account has note which equals Hitler to Soros... Why should SQLite backend be replaced with LMDB? UPD: Ooops, LMDB was forked a long time…
OpenLDAP is very heavily used by a lot of companies, in particular mobile operators that put it under very heavy load, so I'd be reasonably confident of its reliability.
I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
I got to the end of that without really understanding what this is solving, what it does, or how. How do you handle changing upstream files locally without forking? Do you just, keep changes in a separate configuration format that is applied lazily at built time? I've never had issues with maintaining a fork anyways.
The main advantage over plain "patch" is that it is more powerful in the face of upstream changes. For example if you rename the upstream file, you have no good way to represent this in .patch, but that project allows is. There also a way to specify patch using function name, which should make it more robust in face of upstream changes.
As for my opinion, this seems like an incremental improvement over existing tools. I'd prefer a simple shell script that does "git checkout ... && mv ... && cp .. && patch ..." over something fancy like this.
I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
Article doesn't tell me why it's better than git's subtree merge.
I'd say the most interesting thing on that site is the Not-Forking idea[1]. 1. https://lumosql.org/src/not-forking/doc/trunk/README.md
Instead of having a fork, you have a configuration that says "checkout x then apply changes a,b,c".
Earlier quoted context omitted.
FWIW, I've been running a system with roughly 100K users, about 25 qps on average, with a single SQLite file for several years. No issues with data.
That's... pretty amazing. It sounds crazy to me, I'm obsessive about hourly backups, but do you use something like Litestream to keep copies?
Earlier quoted context omitted.
Yes, specifications which could almost certainly be applied with a custom merge drivers or strategy rather than trying to come up with a clever name and hand baking a custom toolchain to do what you can already do with Git
Not all projects use git.
Earlier quoted context omitted.
You mean like #define + #ifdef?
Very niche but: https://github.com/SpongePowered/Mixin It's not really possible to implement in the same way for many other languages, but something like this but for source code transformations (rather than bytecode, or machine code for compiled languages) is probably the kind of thing they're thinking of. Mixin allows you to insert code into methods, modify calls to functions, read/write to local variables, modify…
Earlier quoted context omitted.
The "plan" is to take out the contaminated code and rewrite it.
If the rights holder is particularly litigious then I could see them suing even if you agreed to take out their code under the argument that you've distributed it and profited from it. I don't know if there's been any cases of this historically but I'd be surprised if there hasn't been.