3 ms·
> It's not meant to be a local version control system, unless you enjoy running local Kubernetes clusters (which I have to do, but don't enjoy). You should be
by chipdart 2y ago
> It's not meant to be a local version control system, unless you enjoy running local Kubernetes clusters (which I have to do, but don't enjoy).
You should be clear about what is a major design trait, and arguably a major design flaw.
Also, there is already standard terminology for this: centralized VCS. I don't understand why you decided to avoid objective descriptions of your project's single most important design trait and instead resort to vague meaningless buzzwords like "cloud-native" or "real-time". In fact, in light of this those terms start to sound like weasel words used to deceive the reader.
- SBArbeit 2y agoWhen I hear "cloud-native" I think "built to scale up well". As opposed to "built to run on file servers" which means "doesn't scale well at all". Is that just me? Also, [1]. I start by saying it's centralized. I'm proud of it. It's the right direction for moving version control forward. And modern use of Git isn't really distributed anyway; it's centralized. We don't push to production from our dev boxes. [1] https://github.com/ScottArbeit/Grace/blob/main/docs/Frequently%20asked%20questions.md https://github.com/ScottArbeit/Grace/blob/main/docs/Frequent....
- roelschroeven 2y agoHm. To me, cloud-native screams and PaaS completely out of my control and completely subject to the whims of some company that does not have my best interest in mind. It implies the impossibility of firing up some local instance for experimenting without having fear of leaving traces. In short, something to be avoided if possible.