Re: [sqlite] fixing time-warp

[Stephan Beal]

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

[Andreas Kupries]

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

[E. Timothy Uy]

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

[Stephan Beal]

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

[E. Timothy Uy]

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

[E. Timothy Uy]

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

[Richard Hipp]

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

[Warren Young]

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

[E. Timothy Uy]

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

[Richard Hipp]

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

[E. Timothy Uy]

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(,
>>   "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=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

[E. Timothy Uy]

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(,
>   "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=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

[E. Timothy Uy]

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(,
  "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=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

[Richard Hipp]

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=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