121–130 of 185 posts
Earlier quoted context omitted.
Would be very curious to hear more about issues with proxy servers (where were they required?), overheads (do you mean RAM usage?) and locking.
Sure keep in mind that my data is a little old but last time I peeked into the git LFS space it seemed like there were still a few gaps. First, most of my background in this area comes from gamedev so YMMV if the same applies in your use cases. For our usage we'd usually have a repo history size that crossed the 1TB mark and even upwards of 2-3TB in some cases. The developer sync was 150-200GB, the art sync was close…
In my case it’s different since Git isn’t accessed by users directly, rather I’m working on some tools that work on top of Git (on user’s machine). Data is primarily text-based, though sometimes binary assets come up (options for offloading them out of Git are being investigated).
So far there were no major issues. I predict degradation over time as repos grow in size and history (Git is not unique in this regard, but it’ll probably be more rapid and easier to observe with Git), so we might start using partial cloning.
(I stand by the idea that using straight up Git for data is something to consider, but with an amendment that it’s predominantly text data, not binary assets.)
What people usually miss about these things is normal version control benefits hugely from content addressing and normal forms. The salient aspect of relational data is that it's cyclic, this makes content addressing unable to provide normal forms on it's own (unless someone figures out how to Merkle cylic graphs!), but the normal form can still made other ways. The first part is easier enough, store rows in some ord…
I’m on my phone and don’t have a ton of time to respond right now, but I’d recommend reading our docs. We’re working on a lot of what you mention.
(Also, we’re hiring for backend and frontend roles. See my comment history for more.)
[0] https://www.splitgraph.com/docs/concepts/objects
[1] https://www.splitgraph.com/workspace/ddn?layout=hsplit&query...
Earlier quoted context omitted.
Both. Schema changes are versioned like everything else. But depending on what the change is, it might make merges difficult. (I haven’t used it; I just read the blog.)
BTW. I wish all databases versioned their schema and kept full history. This should be a standard feature.
Wordpress would have benefited from this. What a lot of webmasters want is, test the site locally, then merge it back. A lot of people turned to Jekyll or Hugo for the very reason that it can be checked into git, and git is reliable. A static website can’t get hacked, whereas anyone who has been burnt with Wordpress security fail knows they’d prefer a static site. And even more: People would like to pass the new webs…
they have a theme preview now. :)
This is absolutely fascinating, conceptually. However, I'm struggling to figure out a real-world use case for this. I'd love if anyone here can enlighten me. I don't see how it can be for production databases involving lots of users, because while it seems appealing as a way to upgrade and then roll back, you'd lose all the new data inserted in the meantime. When you roll back, you generally want to roll back changes…
I am not associated to Dolt, but I really like the idea of Dolt personally. I do see use cases, but not without challenges. One of the main use cases you can see them targeting, and that I think makes a ton of sense, is providing tools for collecting, maintaining and publishing reference data sets using crowd sourcing. For example, they are doing this with hospital charge codes (a.k.a. chargemaster data). Hospitals i…
not so sure how well it would work for live data sources that update with time as it could encourage people to apply more ad-hoc edits as opposed to getting their version controlled jobs to work 100%, but who knows, maybe that would be a net win in some cases?
Earlier quoted context omitted.
Git is used prolifically in the tech industry. What on earth are you talking about?
Being needlessly complicated seldomly stops the tech industry from using something as long as the complexity is slightly out of the way.
Is a pretty strong statement, especially given many tech companies use it exactly for this purpose.
Git might have a learning curve, and sure, it's not the simplest. But "barely usable" is hyperbole in the face of actual evidence.
I'm not defending Git specifically ; other SVNs are just as viable. The quoted statement seems a bit ridiculous.