Re: [fossil-users] fast-import crash (mark not declared)

On Fri, Jun 08, 2018 at 05:06:23PM +0300, Petr Ovtchenkov wrote: > During attempt to export fossil's repo (tcl, http://core.tcl.tk/tcl) to git I > face with > fast-import (fossil export --git --export-marks ../tcl-fossil/fossil.marks > ../tcl.fossil | git > fast-import

Re: [fossil-users] fast-import crash (mark not declared)

On Fri, 8 Jun 2018 10:27:51 -0400 Richard Hipp wrote: > On 6/8/18, Petr Ovtchenkov wrote: > > Hello, > > > > During attempt to export fossil's repo (tcl, http://core.tcl.tk/tcl) to git > > I face with > > fast-import (fossil export --git --export-marks ../tcl-fossil/fossil.marks > >

Re: [fossil-users] fast-import crash (mark not declared)

On 6/8/18, Petr Ovtchenkov wrote: > Hello, > > During attempt to export fossil's repo (tcl, http://core.tcl.tk/tcl) to git > I face with > fast-import (fossil export --git --export-marks ../tcl-fossil/fossil.marks > ../tcl.fossil | git > fast-import --export-marks=../tcl-fossil/git.marks) crash:

Re: [fossil-users] fast-import crash (mark not declared)

On Fri, 17 Feb 2017 00:19:08 -0600 Artur Shepilko wrote: > To summarize the findings: > - Sqlite Fossil repo has a number of special cases that do not export > directly, resulting in "git fast-import" crash. > - To accomplish the export, one needs to apply the following

Re: [fossil-users] fast-import crash (mark not declared)

Hi, On 2017-02-17 at 07:37 -0500 Richard Hipp wrote: >On 2/17/17, Rafal Bisingier wrote: >> >> Out of curiosity: what will happen, when commited parent have timestamp >> far away in future? > >You could move the defective commit onto a branch (a branch

Re: [fossil-users] fast-import crash (mark not declared)

On 2/17/17, Rafal Bisingier wrote: > > Out of curiosity: what will happen, when commited parent have timestamp > far away in future? You could move the defective commit onto a branch (a branch named "mistake" is a popular choice). Or you could change the date on the defective

Re: [fossil-users] fast-import crash (mark not declared)

Hi, On 2017-02-17 at 07:03 -0500 Richard Hipp wrote: >On 2/17/17, Richard Hipp wrote: >> On 2/17/17, Rafal Bisingier wrote: >>> >>> Shouldn't Fossil at least warn user trying to commit a child wit >>> timestamp earlier than parent? >>

Re: [fossil-users] fast-import crash (mark not declared)

On 2/17/17, Richard Hipp wrote: > On 2/17/17, Rafal Bisingier wrote: >> >> Shouldn't Fossil at least warn user trying to commit a child wit >> timestamp earlier than parent? > > I think it does that, now. Confirmed: That fix went in 7 years ago:

Re: [fossil-users] fast-import crash (mark not declared)

On Fri, 17 Feb 2017 00:04:29 -0600 Artur Shepilko wrote: > ... > I just realized that the check-in date may be altered via "fossil > amend --date" or from UI via check-in's edit submenu. > This will add the tag "date=" and update the check-ins MTIME. > > Looks like both

Re: [fossil-users] fast-import crash (mark not declared)

Hi On Fri, 17 Feb 2017 at 06:07 -0500 Richard Hipp wrote: > On 2/17/17, Rafal Bisingier wrote: > > > > Shouldn't Fossil at least warn user trying to commit a child wit > > timestamp earlier than parent? > > I think it does that, now. The timewarps all

Re: [fossil-users] fast-import crash (mark not declared)

On 2/17/17, Rafal Bisingier wrote: > > Shouldn't Fossil at least warn user trying to commit a child wit > timestamp earlier than parent? I think it does that, now. The timewarps all happened a while ago. -- D. Richard Hipp d...@sqlite.org

Re: [fossil-users] fast-import crash (mark not declared)

Hi On Thu, 16 Feb 2017 at 14:15 -0800 Ross Berteig wrote: > Sure, we'd all love it if everyone kept their clocks in sync, but in the real > world skew is simply going to happen. In the absence of a central server to > provide the authoritative time stamp, a DVCS like

Re: [fossil-users] fast-import crash (mark not declared)

To summarize the findings: - Sqlite Fossil repo has a number of special cases that do not export directly, resulting in "git fast-import" crash. - To accomplish the export, one needs to apply the following fixes to the __local__ clone of the Sqlite Fossil repo: fossil set autosync off fossil

Re: [fossil-users] fast-import crash (mark not declared)

Richard, Thank you for the details. I just realized that the check-in date may be altered via "fossil amend --date" or from UI via check-in's edit submenu. This will add the tag "date=" and update the check-ins MTIME. Looks like both timeline and export indeed pick up the updated MTIME. I

Re: [fossil-users] fast-import crash (mark not declared)

On 2/16/17, Artur Shepilko wrote: > Is this some undocumented Fossil feature which is supposed to allow > overriding of the commit timestamp? Yes. You can change the displayed date of any check-in using a date tag. This feature is designed to fix check-ins that were made

Re: [fossil-users] fast-import crash (mark not declared)

Hmm, another look reveals some surprises: The "future" parent commit (https://www.sqlite.org/src/info/655991ec8a781d67) also has a "date" tag added, apparently in attempt to rectify the timeline: date=2010-09-28 19:16:47 added by [5fd7e19e] on 2010-09-28 19:19:21 Similar situation is with the

Re: [fossil-users] fast-import crash (mark not declared)

Indeed, in export.c the commits are lined up chronologically. There's a way to try to catch such inconsistencies by tracking when the "from :mark" gets freshly incremented (that is the parent has not been exported yet): src/export.c::~581 int next_mark = unused_mark; zMark =

Re: [fossil-users] fast-import crash (mark not declared)

On Thu, Feb 16, 2017 at 02:15:25PM -0800, Ross Berteig wrote: > I'd argue the problem here is with Git. Actually, git is not at fault here. We do the export chronologically as it is much easier to do than computing a topologically sorted output. Joerg

Re: [fossil-users] fast-import crash (mark not declared)

On 2/16/2017 1:11 PM, Artur Shepilko wrote: This fix seems to allow the git fast-import to proceed past this ... until it finds another inconsistency, unrelated to the one above. This time it's with commit: https://www.sqlite.org/src/info/3f30f00a384d2358 Again, looking at the timeline

Re: [fossil-users] fast-import crash (mark not declared)

Looking closer at the timeline and manifests shows that the inconsistency is with https://www.sqlite.org/src/info/590d4ac1ee0db824 which lists as its parent a tag's manifest (https://www.sqlite.org/src/info/f228c7ca0682c370). Normally the link should be to tag's target object, which in this case

Re: [fossil-users] fast-import crash (mark not declared)

> commit refs/heads/shunning_error > mark :56263 > committer drh 1257360677 + > data 24 > * from :56264 This is a curious case: looks like the branch:"shunning_error" starts off a tag (https://www.sqlite.org/src/info/f228c7ca0682c370f8c43) That is its parent is a commit edit/amend