I am not behind http://repo.or.cz/w/sqlite.git - though Kyle (the one behind it) has some good ideas that would be nice to get into fossil. But he doesn't care to try to get them into fossil. I do. Please don't misinterpret the answers below as any kind of disrespect for DRH, SQLite or fossil - they are all held in high regard.
> 1. Why is it a good idea for you, E. Timothy Uy, to dump the SQLite code > repo into a Git repo? What does this achieve, that keeping it in Fossil > does not? > Like fossil, I use SQLite code as part of a larger project. This larger project is using Git. I would like to reference all third-party code as Git submodules - this is already done for components that are SVN-based. Previously I had an untracked folder holding fossil repositories and I briefly considered some kind of macro or script to fossil clone - but I like how Git submodules also keep track of the particular commit that is used by the master repo. > 2. Why is it a good idea for our BDFL, D. Richard Hipp, to modify the > SQLite repo to make it easier for you to dump it into a Git repo? Keep in > mind that the costs here are not just his time, but also the loss of a test > case. I don't think DRH needs modify the repo to make it easier to help _me_ dump it into a Git repo. In fact, (see #3), I no longer think the time-warps should be fixed at all. However, I do want to point out that 1. There are two existing tags that fix the two time-warps. However, these have been un-fixed without deleting the fixing tags. This is confusing. Maybe the tags should be deleted? Or maybe there are two more tags somewhere that unfix the fixes? b. SQLite is the crown jewel example of the beauty of fossil. Fossil offers "fossil export --git repo.fossil | git fast-import". Why should this break for SQLite? It shouldn't. c. It is a matter of perception. If SQLite is good example of fossil, putting your code into fossil means never getting it out again. That is scary. I don’t think you can convince anyone that #2 is a good idea, but I’m > curious about why #1 is a good idea. > > Bonus persuasion point 3: Why not persuade the Git people to modify their > tool to cope with time warps? Isn’t their major value proposition w.r.t > the other open source DVCSes that Git is more powerful and flexible? Here > we see Fossil doing something Git cannot or will not do, and it’s not a > matter of mission scope, as with the bug tracker or wiki features of Fossil. The problem is ultimately not time-warps. DRH can confirm - the problem is actually inside fossil and sqlite.fossil. Very early on in sqlite.fossil there are entries in the plink table where the parent id (pid) is greater than the commit id (cid). There are over a thousand of these. I suspect that because of this, the --git export function sorts the commits by mtime instead of by objid. But ideally the export function should sort by objid with pid always less than cid. When sorting by mtime, time-warps cause the scenario where a commit is exported which refers to a parent which has not been mentioned. This is what causes the Git fast-import function to choke. The interim fix is to use a tag to change the time, then export. If I had more brain cells, I could perhaps invent a way to efficiently use the plink table to generate the proper export list where parents always come before children regardless of mtime. Respectfully, Tim > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
