3 ms·

> In git in comparison, it is for example much easier to find the parents of a commit than its children. Sure, but both are really cheap.

cryptonector 6y ago
Well, no, in huge repositories with lots of branches it's not. But this is true for Fossil as well. IIRC MSFT did a study with the Windows repository showing that a relational approach to VCS bloated the repository too much, and out of this grew the Bloom filter approach to speeding up with git blame/log.
- balfirevic 6y ago
  > But this is true for Fossil as well. Since I don't know anything about how Fossil stores commit metadata this might a naive question - but why is that? I would guess that being able to efficiently query all the children of particular commit should be just an index away.
  - microcolonel 6y ago
    > I would guess that being able to efficiently query all the children of particular commit should be just an index away. Yes, but where will you find the space, and when will you compute it?
    - balfirevic 6y ago
      I'm not sure I understand what you mean. I was talking about Fossil, which uses SQLite under the hood, which would then maintain the index whenever data in it is modified.
      - cryptonector 6y ago
        Scale. Microsoft couldn't make a SQL VCS work. Maybe it's because they tried to use SQL Server instead of PostgreSQL, I dunno :) but IIRC the amounts of metadata involved essentially meant that they had no hope of doing git-like cloning: it was too much to clone.
        sitkack 6y ago
        You would need to implement a persistent datastructure, but without refcounts, you would have to do a gc. I guess you could do a refcount tree and only RC at the last common node. Really atime is the devil. Funny thing is, is that all modern higher level systems have some form of data access logging, which is what you want anyway. So why not form some easily compressible event log?

cryptonector 6y ago

Well, no, in huge repositories with lots of branches it's not. But this is true for Fossil as well. IIRC MSFT did a study with the Windows repository showing that a relational approach to VCS bloated the repository too much, and out of this grew the Bloom filter approach to speeding up with git blame/log.

balfirevic 6y ago
> But this is true for Fossil as well. Since I don't know anything about how Fossil stores commit metadata this might a naive question - but why is that? I would guess that being able to efficiently query all the children of particular commit should be just an index away.
- microcolonel 6y ago
  > I would guess that being able to efficiently query all the children of particular commit should be just an index away. Yes, but where will you find the space, and when will you compute it?
  - balfirevic 6y ago
    I'm not sure I understand what you mean. I was talking about Fossil, which uses SQLite under the hood, which would then maintain the index whenever data in it is modified.
    - cryptonector 6y ago
      Scale. Microsoft couldn't make a SQL VCS work. Maybe it's because they tried to use SQL Server instead of PostgreSQL, I dunno :) but IIRC the amounts of metadata involved essentially meant that they had no hope of doing git-like cloning: it was too much to clone.
      - sitkack 6y ago
        You would need to implement a persistent datastructure, but without refcounts, you would have to do a gc. I guess you could do a refcount tree and only RC at the last common node. Really atime is the devil. Funny thing is, is that all modern higher level systems have some form of data access logging, which is what you want anyway. So why not form some easily compressible event log?