Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why SQLite does not use Git (2018)

sqlite.org

Post reply on HN
Print view View original

121–130 of 454 posts

Re: Why SQLite does not use Git (2018)

#121

Post by genocidicbunny »

forrestthewoods wrote: post #91
gorjusborg wrote: post #81

Earlier quoted context omitted.

Binaries aren't source code. It sounds like you want a versioned file system, not source control. Git is a beautiful solution for its use case.

Git is a “distributed version control system” (DVCS). You’re just adding the term “source code” for no particular reason. I make video games. Video games contain far more data than mere source code. Almost all game devs use Perforce because Git is insufficient. Artists and designers desperately need more version control in their lives. They are mostly absent because their programmers use Git which is insufficient. It…

Amen. I also work[ed] in video games, and this rings very true to me. Git worked well enough for the programmers, but when you're dealing with artists, producers, designers, writers, audio engineers all needing to share work on assets that are also tied to specific versions of source, Git falls apart.

One studio I was at actually had a custom VCS that was a combination of SVN + homebrew asset versioning that worked decently well. By that I mean we all hated the shit out of having to use it, but it worked better than most anything we could get our hands on at the time for a reasonable price.

Re: Why SQLite does not use Git (2018)

#122

Post by andersa »

beebmam wrote: post #55
bane wrote: post #41

Earlier quoted context omitted.

I have no idea why Richard focuses on such things but: I'm old enough to remember when developers spent time making sure they could plow all of their build assets into a single binary distributable. It often had kind of a zest to it and when you dealt with software had directories full of stuff it looked both "corporate" and "sloppy". I've never quite gotten over the feeling that the piles of dynamically linked libra…

If you're using TLS/crypto in an app, it's scary to statically bundle those libraries.

The situation on windows is fascinating: everyone links these libraries dynamically, and yet, there are about two hundred of them on my system, every application using its own uniquely outdated version.

Re: Why SQLite does not use Git (2018)

#123

Post by backendanon »

qbasic_forever wrote: post #101
thayne wrote: post #98

Earlier quoted context omitted.

FWIW, that isn't actually part of the core git binary. Because unlike fossil, git is a collection of executables, not just one.

Yes, which is why git is a pain in the butt to install and you have to rely on your OS packages (which includes all the kitchen sink stuff) or a GUI installer with all the necessary dependencies vs. Fossil which is just download executable and done.

git...is difficult to install? What's difficult about apt-get install git?

Re: Why SQLite does not use Git (2018)

#124

Post by yjftsjthsd-h »

blitz_skull wrote: post #92

[flagged]

> It’s easy one of the most powerful, flexible,

Probably, yeah.

> and if you take the time to learn it, SIMPLE models for version control.

... And there it all falls apart. In practice, git requires a massive amount of learning to use competently, to the point that using something else just to avoid the learning curve is fairly reasonable.

Re: Why SQLite does not use Git (2018)

#125

Post by paulryanrogers »

inferiorhuman wrote: post #48
reaperducer wrote: post #34

Earlier quoted context omitted.

if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. That's pretty much the opposite of progress. At one time, 99.9% of developers used CP/M. At time, 99.9% of web was done in PHP. At one time, 99.9% of developers IBM XTs. At one time 99.9% of developers used SourceForce and SVN. Stuff changes. Monoculture is bad for the tech industry.

On the one hand I'm inclined to agree about monoculture, on the other I've worked at a company where one employee dictated that we use bzr. Basically everything was an order of magnitude more difficult through minimal fault of bzr. None of the third party tooling worked with bzr, or if something did have bzr support it was dropped ages ago. It's kind of the same situation with Github. The pain in moving away from it…

Having been that person (albeit before Git was the one true way), I'm sorry. But seemed so nice and had solid externals and sparse checkouts back in the day. And as bad as it got for us, it still felt easier to pick up and use than early Git.

Re: Why SQLite does not use Git (2018)

#126

Post by kibwen »

beebmam wrote: post #55
bane wrote: post #41

Earlier quoted context omitted.

I have no idea why Richard focuses on such things but: I'm old enough to remember when developers spent time making sure they could plow all of their build assets into a single binary distributable. It often had kind of a zest to it and when you dealt with software had directories full of stuff it looked both "corporate" and "sloppy". I've never quite gotten over the feeling that the piles of dynamically linked libra…

If you're using TLS/crypto in an app, it's scary to statically bundle those libraries.

On a closed-source system, sure. On a system where you have the source, you have the option to rebuild your binaries.

Re: Why SQLite does not use Git (2018)

#127

Post by ogurechny »

georgemcbay wrote: post #10
NBJack wrote: post #4

[flagged]

Site worked fine for me, but in any case, SQLite is 23 years old now and widely used all over the place and well understood by many thousands of developers... the time has long since passed when its reputation might hinge on the moment-to-moment uptime of its own home page.

It's probably not availability issues. From what I've seen in Fossil discussions, sqlite.org is just a couple of Fossil instances (code and documentation) and a pack of HTML pages behind a simple web server. They had to invent an ad-hoc scrape protection for computationally expensive requests, and probably have something like that for DoS protection. It is possible that it is not fair because of simplicity, and temporarily blocks certain amount of less lucky visitors. Intermittent inaccessibility of project websites seems regular to me.

Re: Why SQLite does not use Git (2018)

#128

Post by avikalp »

qbasic_forever wrote: post #86
ohthatsnotright wrote: post #21

I'm glad Fossil works for them, but this line is bothered me: > In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. That one binary contains all the functionality of core Git and also GitHub and/or GitLab. It manages a community server with wiki, bug tracking, and forums, provides packaged downloads for consumers, login managements, and so forth, with no extra software require…

Git actually is bundling a lot of stuff you probably don't realize. Run 'git instaweb' for example and it will spin up a local CGI server and perl CGI script to give a very simple web UI: https://git-scm.com/docs/git-instaweb Fossil isn't much different in core functionality here. There is a ton of email client integration and functionality in git too that most people who only use GitHub probably have absolutely no i…

I tried that (primarily because I didn't know about it and was excited), but it didn't work. It needs me to install "lighttpd" to work. And the steps to install that are not straightforward.

I like that a lot of functionality is not bundled up in the git that I have already installed in my computer, but at the same time, I agree with the fact that adding these separate binaries is not easy as a user.

Re: Why SQLite does not use Git (2018)

#129

Post by zeroimpl »

tootie wrote: post #102
zeroimpl wrote: post #100

Seems like a textbook example of NIH to me. By the time you understand git well enough to design a good replacement, you’re bound to be an expert and ought to appreciate more the design of git. If you don’t like the lack of a good GUI or web application, you can just build one that works the way you want and still works with git.

Not to be whiny, but we had better versions of git before git was the standard. I'm thinking specifically of Mercurial.

I thought they both started at the same time? Unless you are implying early versions of git were worse, which wouldn't surprise me.

I know git has a learning curve, but the only times I really see junior people have issues is when they are trying to do things that wouldn't have been easy with earlier VCS systems either. And it seems like git isn't going away, so it's worth putting the time into learning it.

Re: Why SQLite does not use Git (2018)

#130

Post by thunderbong »

IMHO, for software developers, a version management system is a tool, just like an IDE, or the underlying OS. The less they need to fiddle with these tools, the more productive they are.

Having worked with multiple version management systems, for me, Fossil hits the perfect sweet spot. You literally just set it up and forget about it.

Post reply on HN