3 ms·

Others having mentioned the terror that was Clear Case, but I just want to highlight one of its bad features: everything was stored in a relational DB. And cons

Others having mentioned the terror that was Clear Case, but I just want to highlight one of its bad features: everything was stored in a relational DB. And consistency was not guaranteed, so at one point all the code was corrupted. After recovery from the backup, it was retired with vengence, and everything went back to RCS and CVS. When I wanted everyone to switch to Git or Mercurial (~2007) the main questions were about branch merges (MUCH easier in git than CVS) and the reliability of the version storage. Many have now moved back to a centralised model of control (github), even if they have many partial copies. The incredibly RDBMS (non-git) method of managing the meta-data of github systems is very disappointing, but not surprising. If github is 4th gen, then I'm hoping for 5th gen, where all SE meta data is also available as a replicated database, which you can spin up with a local httpd.

ptman 8y ago
You mean like fossil https://fossil-scm.org/ https://fossil-scm.org/ ?
- angry_octet 8y ago
  While there are nice features in fossil (and sqlite is fantastic), but it is not git compatible. If the code and artifacts were kept in git underneath then exchanging code with other repos would be seamless. I don't understand why they rejected keeping tickets as files in a version control system (separate from the code), instead of blobs. It just seems unfriendly to manipulation by other tools. Philosophically, I like that git can be extended with small tools and modules instead of a monolithic executable.
alkonaut 8y ago
Git is pretty agnostic to storage. There are implementations that use RDBMS for storage quite successfully (TFS/VSTS). It wouldn’t surprise me if a lot of queries can be significantly faster to perform over git repos stored this way. https://www.richard-banks.org/2014/02/tfs-internals-how-does-tfs-store-git.html https://www.richard-banks.org/2014/02/tfs-internals-how-does...
- angry_octet 8y ago
  It is unclear from this if the packfiles are actually stored only in the database, it sounds like he is saying they are stored in the file system (and accessed from there for git operations), but there is a copy in the DB too (updated after transactions have committed? Or in the commit but after the local file?). So it sounds like they are keeping repo metadata in tables to speed up queries, manage parallel access, etc. That is sensible, but quite different to keeping every code change as an SQL database entry.

ptman 8y ago

You mean like fossil https://fossil-scm.org/ https://fossil-scm.org/ ?

angry_octet 8y ago
While there are nice features in fossil (and sqlite is fantastic), but it is not git compatible. If the code and artifacts were kept in git underneath then exchanging code with other repos would be seamless. I don't understand why they rejected keeping tickets as files in a version control system (separate from the code), instead of blobs. It just seems unfriendly to manipulation by other tools. Philosophically, I like that git can be extended with small tools and modules instead of a monolithic executable.

alkonaut 8y ago

Git is pretty agnostic to storage. There are implementations that use RDBMS for storage quite successfully (TFS/VSTS). It wouldn’t surprise me if a lot of queries can be significantly faster to perform over git repos stored this way. https://www.richard-banks.org/2014/02/tfs-internals-how-does-tfs-store-git.html https://www.richard-banks.org/2014/02/tfs-internals-how-does...

angry_octet 8y ago
It is unclear from this if the packfiles are actually stored only in the database, it sounds like he is saying they are stored in the file system (and accessed from there for git operations), but there is a copy in the DB too (updated after transactions have committed? Or in the commit but after the local file?). So it sounds like they are keeping repo metadata in tables to speed up queries, manage parallel access, etc. That is sensible, but quite different to keeping every code change as an SQL database entry.