[tombert]

If I recall correctly, the Fossil SCM uses SQLite under the covers for a lot of its stuff.

Obviously that's not surprising considering its creator, but hearing that was kind of the first time I had ever considered that you could translate something like Git semantics to a relational database.

I haven't played with Pgit...though I kind of think that I should now.

[anitil]

The sqlite project actually benefited from this dogfooding. Interestingly recursive CTEs [0] were added to sqlite due to wanting to trace commit history [1]

[0] https://sqlite.org/lang_with.html#recursive_query_examples

[1] https://fossil-scm.org/forum/forumpost/5631123d66d96486 - My memory was roughly correct, the title of the discussion is 'Is it possible to see the entire history of a renamed file?'

[anitil]

On and of course, the discussion board is itself hosted in a sqlite file!

[20after4]

When you import a repository into Phabricator, it parses everything into a MySQL database. That's how it manages to support multiple version control systems seamlessly as well as providing a more straightforward path to implementing all of the web-based user interface around repo history.

[gjvc]

"If I recall correctly, the Fossil SCM uses SQLite under the covers for a lot of its stuff."

a fossil repository file is a .sqlite file yes

[ptdorf]

So SQLite is versioned in SQLite.

[yjftsjthsd-h]

Yep:) To be fair, I expect git to be stored in git, mercurial to be in mercurial, and... Actually now I wonder how svn/cvs are developed/versioned.

[deepsun]

SVN in SVN for sure, it's a well made product. The market just didn't like it's architecture/UX that doctates what features available.

CVS is not much different from copying files around, so would not be surprised if they copied the files around to mimic what CVS does. CVS revolutionized how we think of code versioning, so it's main contribution is to the processes, not the architecture/features.

[vidarh]

The market did like it just fine until Git came around. It just had a very brief moment in the sun....

[tombert]

My first software job, I was a junior person, and every Friday, we would have The Merge, where we'd merge every SVN branch into trunk. We always spoke of it like it was this dreadful proper noun, like Voldemort or something.

The junior engineers were the ones doing this, and generally my entire day would be spent fixing merge conflicts. Usually they were easy to resolve, but occasionally I'd hit one that would take me a very long time (it didn't help that I was still pretty inexperienced and consequently these things were just sort of inherently harder for me). I just assumed that this was the way that the world was until I found `git-svn`.

`git-svn` made a task that often took an entire day take something like 45 minutes, usually much less. It was like a light shining down from heaven; I absolutely hated doing The Merge, and this just made it mostly a solved problem.

After that job, I sort of drew a soft line in the sand that I will not work with SVN again, because at that point I knew that merging could be less terrible. I wasn't necessarily married to git in particular, but I knew that whatever the hell it was that SVN was doing, I didn't like it.

[tombert]

Makes sense, I haven't used the software in quite awhile.

[adastra22]

Git was a (poor) imitation of the monotone DVCS, which stored its data in sqlite.

[xeubie]

True, git poorly imitated monotone's performance problems.

[ImGajeed76]

you should! "go install" it and you're up in a minute.