Re: [sqlite] fixing time-warp
On Wed, Nov 5, 2014 at 6:24 PM, Andreas Kupries wrote: > How about looking into > > fossil test-shortest-path > > and see how it follows the path of revisions. ? > Oh, but were's the fun in rolling a wheel someone else already made round ;). (moments later...) It turns out i already ported the whole shortest-path/PathNode bits to libfossil, but it hasn't yet been used anywhere except test code. Good thing Fossil remembers everything so well, because i only vaguely remember writing it. [stephan@host:~/cvs/fossil/libfossil/f-apps]$ ./f-sanity -1 fcli.appName=./f-sanity Checkout dir=/home/stephan/cvs/fossil/libfossil/ Checkout db=/home/stephan/cvs/fossil/libfossil/_FOSSIL_ Repo db=/home/stephan/cvs/fossil/libfossil.fsl test_path_1()... directOnly=1, oneWayOnly=0 Versions d7927376fa9d (5534) to c10d7424ae4c (5525): 3 steps #1: 5534 #2: 5532 begat 5534 #3: 5528 begat 5532 #4: 5525 begat 5528 checkout UUID=220da67a06ee577d4667718b2ffe2f94c48ca338 (RID 6660) Cached statement count: 3 If you made it this far, no assertions were triggered. Now try again with valgrind. Total run time: 0.007919 seconds of CPU time Interestingly, that test uses rid comparison for determining whether to say "begat" or "derives from" (not seen above), but i've learned in the mean time the rid comparison isn't strictly reliable because it's legal for artifacts to get blobified (getting a blob.rid value) in an arbitrary order. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] fixing time-warp
How about looking into fossil test-shortest-path and see how it follows the path of revisions. ? On Wed, Nov 5, 2014 at 9:04 AM, E. Timothy Uy wrote: > Thank you, that is helpful information. > > On Tue, Nov 4, 2014 at 11:52 PM, Stephan Beal wrote: > >> On Wed, Nov 5, 2014 at 7:07 AM, E. Timothy Uy wrote: >> >> > 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. >> >> >> Those IDs are _transient_, not part of the historical record. The "child ID >> comes before parent ID" behaviour also appears on completely benign repos >> (i've seen it before in my own while testing libfossil). >> >> >> >> > 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. >> > >> >> i've also attempted something similar in libfossil, but haven't been >> successful. The RIDs cannot be used to figure it out, and neither can >> mtime. The only 100% reliable way i know of traversing the history is to >> read each manifest, as the P-cards give us that piece of context we need to >> know the ordering. >> >> -- >> - stephan beal >> http://wanderinghorse.net/home/stephan/ >> http://gplus.to/sgbeal >> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of >> those who insist on a perfect world, freedom will have to do." -- Bigby >> Wolf >> ___ >> 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 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] fixing time-warp
Thank you, that is helpful information. On Tue, Nov 4, 2014 at 11:52 PM, Stephan Beal wrote: > On Wed, Nov 5, 2014 at 7:07 AM, E. Timothy Uy wrote: > > > 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. > > > Those IDs are _transient_, not part of the historical record. The "child ID > comes before parent ID" behaviour also appears on completely benign repos > (i've seen it before in my own while testing libfossil). > > > > > 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. > > > > i've also attempted something similar in libfossil, but haven't been > successful. The RIDs cannot be used to figure it out, and neither can > mtime. The only 100% reliable way i know of traversing the history is to > read each manifest, as the P-cards give us that piece of context we need to > know the ordering. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby > Wolf > ___ > 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
Re: [sqlite] fixing time-warp
On Wed, Nov 5, 2014 at 7:07 AM, E. Timothy Uy wrote: > 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. Those IDs are _transient_, not part of the historical record. The "child ID comes before parent ID" behaviour also appears on completely benign repos (i've seen it before in my own while testing libfossil). > 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. > i've also attempted something similar in libfossil, but haven't been successful. The RIDs cannot be used to figure it out, and neither can mtime. The only 100% reliable way i know of traversing the history is to read each manifest, as the P-cards give us that piece of context we need to know the ordering. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] fixing time-warp
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 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
Re: [sqlite] fixing time-warp
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
Re: [sqlite] fixing time-warp
Maybe E. Timothy Uy is the person behind http://repo.or.cz/w/sqlite.git ? On Tue, Nov 4, 2014 at 7:15 PM, Warren Young wrote: > On Nov 3, 2014, at 7:01 PM, E. Timothy Uy wrote: > > > Is that a philosophical question? :) > > No, it’s a persuasion challenge. > > I’ll propose it in two parts: > > 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? > > 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 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. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] fixing time-warp
On Nov 3, 2014, at 7:01 PM, E. Timothy Uy wrote: > Is that a philosophical question? :) No, it’s a persuasion challenge. I’ll propose it in two parts: 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? 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 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. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] fixing time-warp
Is that a philosophical question? :) On Mon, Nov 3, 2014 at 5:52 PM, Richard Hipp wrote: > On Mon, Nov 3, 2014 at 8:46 PM, E. Timothy Uy wrote: > > > Ok, I now see that you intentionally left 2 time-warps in place. It would > > be helpful to make that as a note for exporting to git. > > > > Why would I want to export the SQLite history to Git? > -- > D. Richard Hipp > d...@sqlite.org > ___ > 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
Re: [sqlite] fixing time-warp
On Mon, Nov 3, 2014 at 8:46 PM, E. Timothy Uy wrote: > Ok, I now see that you intentionally left 2 time-warps in place. It would > be helpful to make that as a note for exporting to git. > Why would I want to export the SQLite history to Git? -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] fixing time-warp
Guess my photo got blocked - https://www.sqlite.org/src/timeline?c=2010-09-28+20:26:44 shows the time-warp but also the tag messages fixing them (which I guess you later unfixed in the db). On Mon, Nov 3, 2014 at 5:46 PM, E. Timothy Uy wrote: > Ok, I now see that you intentionally left 2 time-warps in place. It would > be helpful to make that as a note for exporting to git. It is also > confusing that the tags are there showing that they were fixed. > > On Mon, Nov 3, 2014 at 5:44 PM, E. Timothy Uy wrote: > >> Dear Richard, >> >> It is strange, but if you look at the timeline image I sent (second >> email), your time-warp tag changes are clearly there but did not stick on >> objid 35450 and 35460. I just manually did mine on this end (following your >> same times) and it is now ok, though I feel a bit dirty changing commit >> times! >> >> Leaving the time-warp in place will affect git export. Also, the other >> barrier that blocks git export of the current sqlite version is that in the >> fossil export.c, the pid needs to be filtered by type='ci' as one of the >> parents is type='g' (tag). I have that in some notes in >> http://www.fossil-scm.org/index.html/tktview?name=4013b0a81a >> >> db_prepare(&q3, >> "SELECT pid FROM plink" >> " WHERE cid=%d AND isprim" >> " AND pid IN (SELECT objid FROM event WHERE type='ci')", >> ckinId >> ); >> >> Respectfully, >> Tim >> >> On Mon, Nov 3, 2014 at 5:37 PM, Richard Hipp wrote: >> >>> On Mon, Nov 3, 2014 at 8:13 PM, E. Timothy Uy wrote: >>> >>> > I found some posts in the past describing fixing time-warps using >>> tags. How >>> > does this process get initiated? I found two while trying to export to >>> .git >>> > >>> >>> >>> The test_timewarps webpage will show them all to you. Example: >>> >>> http://www.sqlite.org/src/test_timewarps >>> >>> In the example above, most of the timewarps have been fixed. To fix >>> them, >>> simple edit check-ins and change their time. >>> >>> I intentionally left one timewarp in SQLite unfixed. See the >>> https://www.sqlite.org/src/timeline?p=3f30f00a384d23&d=3f30f00a384d235 >>> timeline. I left this one as a test case for ensuring that Fossil can >>> display timewarps correctly. >>> >>> >>> >>> >>> > >>> > sqlite> SELECT l.*, ep.mtime, ec.mtime FROM plink l LEFT JOIN event ep >>> ON >>> > pid = ep.objid LEFT JOIN event ec ON cid = ec.objid WHERE ep.mtime > >>> > ec.mtime LIMIT 10; >>> > >>> > 35460|35462|1|2455469.2683|2455469.46484954|2455469.2683 >>> > >>> > 35450|35453|1|2455468.35189815|2455468.80332176|2455468.35189815 >>> > >>> > Respectfully, >>> > >>> > Tim >>> > ___ >>> > sqlite-users mailing list >>> > sqlite-users@sqlite.org >>> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >>> > >>> >>> >>> >>> -- >>> D. Richard Hipp >>> d...@sqlite.org >>> ___ >>> 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
Re: [sqlite] fixing time-warp
Ok, I now see that you intentionally left 2 time-warps in place. It would be helpful to make that as a note for exporting to git. It is also confusing that the tags are there showing that they were fixed. On Mon, Nov 3, 2014 at 5:44 PM, E. Timothy Uy wrote: > Dear Richard, > > It is strange, but if you look at the timeline image I sent (second > email), your time-warp tag changes are clearly there but did not stick on > objid 35450 and 35460. I just manually did mine on this end (following your > same times) and it is now ok, though I feel a bit dirty changing commit > times! > > Leaving the time-warp in place will affect git export. Also, the other > barrier that blocks git export of the current sqlite version is that in the > fossil export.c, the pid needs to be filtered by type='ci' as one of the > parents is type='g' (tag). I have that in some notes in > http://www.fossil-scm.org/index.html/tktview?name=4013b0a81a > > db_prepare(&q3, > "SELECT pid FROM plink" > " WHERE cid=%d AND isprim" > " AND pid IN (SELECT objid FROM event WHERE type='ci')", > ckinId > ); > > Respectfully, > Tim > > On Mon, Nov 3, 2014 at 5:37 PM, Richard Hipp wrote: > >> On Mon, Nov 3, 2014 at 8:13 PM, E. Timothy Uy wrote: >> >> > I found some posts in the past describing fixing time-warps using tags. >> How >> > does this process get initiated? I found two while trying to export to >> .git >> > >> >> >> The test_timewarps webpage will show them all to you. Example: >> >> http://www.sqlite.org/src/test_timewarps >> >> In the example above, most of the timewarps have been fixed. To fix them, >> simple edit check-ins and change their time. >> >> I intentionally left one timewarp in SQLite unfixed. See the >> https://www.sqlite.org/src/timeline?p=3f30f00a384d23&d=3f30f00a384d235 >> timeline. I left this one as a test case for ensuring that Fossil can >> display timewarps correctly. >> >> >> >> >> > >> > sqlite> SELECT l.*, ep.mtime, ec.mtime FROM plink l LEFT JOIN event ep >> ON >> > pid = ep.objid LEFT JOIN event ec ON cid = ec.objid WHERE ep.mtime > >> > ec.mtime LIMIT 10; >> > >> > 35460|35462|1|2455469.2683|2455469.46484954|2455469.2683 >> > >> > 35450|35453|1|2455468.35189815|2455468.80332176|2455468.35189815 >> > >> > Respectfully, >> > >> > Tim >> > ___ >> > sqlite-users mailing list >> > sqlite-users@sqlite.org >> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > >> >> >> >> -- >> D. Richard Hipp >> d...@sqlite.org >> ___ >> 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
Re: [sqlite] fixing time-warp
Dear Richard, It is strange, but if you look at the timeline image I sent (second email), your time-warp tag changes are clearly there but did not stick on objid 35450 and 35460. I just manually did mine on this end (following your same times) and it is now ok, though I feel a bit dirty changing commit times! Leaving the time-warp in place will affect git export. Also, the other barrier that blocks git export of the current sqlite version is that in the fossil export.c, the pid needs to be filtered by type='ci' as one of the parents is type='g' (tag). I have that in some notes in http://www.fossil-scm.org/index.html/tktview?name=4013b0a81a db_prepare(&q3, "SELECT pid FROM plink" " WHERE cid=%d AND isprim" " AND pid IN (SELECT objid FROM event WHERE type='ci')", ckinId ); Respectfully, Tim On Mon, Nov 3, 2014 at 5:37 PM, Richard Hipp wrote: > On Mon, Nov 3, 2014 at 8:13 PM, E. Timothy Uy wrote: > > > I found some posts in the past describing fixing time-warps using tags. > How > > does this process get initiated? I found two while trying to export to > .git > > > > > The test_timewarps webpage will show them all to you. Example: > > http://www.sqlite.org/src/test_timewarps > > In the example above, most of the timewarps have been fixed. To fix them, > simple edit check-ins and change their time. > > I intentionally left one timewarp in SQLite unfixed. See the > https://www.sqlite.org/src/timeline?p=3f30f00a384d23&d=3f30f00a384d235 > timeline. I left this one as a test case for ensuring that Fossil can > display timewarps correctly. > > > > > > > > sqlite> SELECT l.*, ep.mtime, ec.mtime FROM plink l LEFT JOIN event ep ON > > pid = ep.objid LEFT JOIN event ec ON cid = ec.objid WHERE ep.mtime > > > ec.mtime LIMIT 10; > > > > 35460|35462|1|2455469.2683|2455469.46484954|2455469.2683 > > > > 35450|35453|1|2455468.35189815|2455468.80332176|2455468.35189815 > > > > Respectfully, > > > > Tim > > ___ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > -- > D. Richard Hipp > d...@sqlite.org > ___ > 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
Re: [sqlite] fixing time-warp
On Mon, Nov 3, 2014 at 8:13 PM, E. Timothy Uy wrote: > I found some posts in the past describing fixing time-warps using tags. How > does this process get initiated? I found two while trying to export to .git > The test_timewarps webpage will show them all to you. Example: http://www.sqlite.org/src/test_timewarps In the example above, most of the timewarps have been fixed. To fix them, simple edit check-ins and change their time. I intentionally left one timewarp in SQLite unfixed. See the https://www.sqlite.org/src/timeline?p=3f30f00a384d23&d=3f30f00a384d235 timeline. I left this one as a test case for ensuring that Fossil can display timewarps correctly. > > sqlite> SELECT l.*, ep.mtime, ec.mtime FROM plink l LEFT JOIN event ep ON > pid = ep.objid LEFT JOIN event ec ON cid = ec.objid WHERE ep.mtime > > ec.mtime LIMIT 10; > > 35460|35462|1|2455469.2683|2455469.46484954|2455469.2683 > > 35450|35453|1|2455468.35189815|2455468.80332176|2455468.35189815 > > Respectfully, > > Tim > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users