As I walked away to do the dishes, these verses from Matthew suddenly came to mind:
The LORD said unto my Lord, Sit thou on my right hand, till I make thine > enemies thy footstool? If David then call him Lord, how is he his son? I think I'll just be quiet now. Blessings, Tim On Tue, Nov 4, 2014 at 10:07 PM, E. Timothy Uy <t...@loqu8.com> wrote: > 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
