>>> The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite
Ok I'll bite. Why?
I can see it's a nice idea - but at some point you add function X, then ten check ins modify that function. what's the difference between looking back at ten and looking forward at ten?
Perhaps I need an example.
If I remember rightly fossil was written by the Sqllite people? I tried it out for a while back in the day - I think it had this store the tickets in the branch alongside the code - it was an appealing idea, but got complicated quickly.
Purely speculative, but I imagine you identify a bug that was introduced in commit X from 2 years ago. You want to answer, "Which supported releases of this product need to be patched?".
isn't that just a question of looping over your release tags and asking whether each one can reach that commit? It's not too hard to script - I don't really see an advantage either way.
Ok I'll bite. Why?
I can see it's a nice idea - but at some point you add function X, then ten check ins modify that function. what's the difference between looking back at ten and looking forward at ten?
Perhaps I need an example.
If I remember rightly fossil was written by the Sqllite people? I tried it out for a while back in the day - I think it had this store the tickets in the branch alongside the code - it was an appealing idea, but got complicated quickly.