Re: [fossil-dev] SQLITE_CONSTRAINT: abort at 41
On Wed, Dec 28, 2016 at 10:31 PM, Andy Bradford wrote: > Thus said Zakero on Thu, 22 Dec 2016 16:07:52 +0400: > > > A few weeks ago, Andy asked me to try to reproduce > > this problem with older versions of fossil. The check-in > > "41c2220934de8cb8d90126d5083df3e95e961b8c" is where the problem first > > appears. This also mirrors the findings in the "Merge failed with SQL > > error" email in the fossil-users mailing list that states the problem > > seems related to the "merge-renames" branch. > > It looks like Richard found some time to fix this: > > http://www.fossil-scm.org/index.html/info/0df5249d51b9c49a > > I've updated the test case (which was failing due to some output > changes, but which are actually correct). Please try building the latest > on trunk to see if it will correctly merge your branch. I would try > myself, but I deleted the copy of your repository that I was testing > against. > > Thanks, > > Andy > -- > TAI64 timestamp: 40005864051a > > > I can confirm that Dr. Hipp's change has fixed the issue that I was encountering. :-) Thank you Dr. Hipp and Andy for looking into this and getting it resolved. Zakero ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] SQLITE_CONSTRAINT: abort at 41
Thus said Zakero on Thu, 22 Dec 2016 16:07:52 +0400: > A few weeks ago, Andy asked me to try to reproduce > this problem with older versions of fossil. The check-in > "41c2220934de8cb8d90126d5083df3e95e961b8c" is where the problem first > appears. This also mirrors the findings in the "Merge failed with SQL > error" email in the fossil-users mailing list that states the problem > seems related to the "merge-renames" branch. It looks like Richard found some time to fix this: http://www.fossil-scm.org/index.html/info/0df5249d51b9c49a I've updated the test case (which was failing due to some output changes, but which are actually correct). Please try building the latest on trunk to see if it will correctly merge your branch. I would try myself, but I deleted the copy of your repository that I was testing against. Thanks, Andy -- TAI64 timestamp: 40005864051a ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] SQLITE_CONSTRAINT: abort at 41
A few weeks ago, Andy asked me to try to reproduce this problem with older
versions of fossil. The check-in
"41c2220934de8cb8d90126d5083df3e95e961b8c" is where the problem first
appears. This also mirrors the findings in the "Merge failed with SQL
error" email in the fossil-users mailing list that states the problem seems
related to the "merge-renames" branch.
On Sat, Nov 12, 2016 at 1:56 AM, Andy Bradford
wrote:
> Thus said Zakero on Sun, 16 Oct 2016 18:45:41 -0500:
>
> > Ran into an interesting problem yesterday when merging branches:
> >
> > SQLITE_CONSTRAINT: abort at 41 in [INSERT INTO
> > vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
> > 21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735]:
> UNIQUE
> > constraint failed: vfile.pathname, vfile.
> > fossil: UNIQUE constraint failed: vfile.pathname, vfile.vid: {INSERT INTO
> > vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
> > 21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735}
> > Rolling back prior filesystem changes...
>
> I have been working with Zakero on this problem, but so far have been
> unable to provide a suitable fix, mostly because I'm not sure which part
> of the code is actually the cause of the problem; that and and lack of
> familiarity with the merge algorithm (is there one?) and code.
>
> I have finally been able to reproduce this problem with a minimal
> test-case. I will include the output below that can trigger the problem.
>
> I've added some additional uncommitted debug code to Fossil to help
> understand what's happening; basically just output the fv table after
> each modification to it. I believe the problem happens because the same
> file is attempted to be added to the vfile table due to failure to
> detect that there was a rename.
>
> In the debug, you'll notice that Fossil first adds in renames for fn,
> and there are none, so there is no output. Then it adds in renames for
> fnp (Pivot) and there are some but none that get added to fv. Then it
> adds in renames for fnm (Merge) and finally there is an entry in the fv
> table for a change from the name pivot (N) to the merge version (M).
> afile is recorded as renamed to Afile due to the merge.
>
> Next, Fossil starts adding in files from the checkout version (V) and
> another row is added to the fv table for the rename. Should it have
> updated the existing entry in fv? Or should it be handled later on with
> the rest of the code that checks for various renames?
>
> Moving on...
>
> After adding files from V, both row 1 and row 2 in fv that represent
> changes to Afile. Adding in files from P updates both rows 1 and 2.
> Adding in files from M doesn't alter row 1 or 2, but does update row 3
> (un unrelated file). No further modifications are made to fv and in the
> end, when Fossil begins updating the vfile table, it ends up trying to
> insert the same filename twice but for different reasons.
>
> I've tried what I thought would be an appropriate fix, but there were a
> handful of failures in merge5, merge_renames and one in merge_exe, so
> either it was the wrong fix, or the tests are biased towards incorrect
> behavior.
>
> Here is the enhanced merge debug output:
>
> $ /tmp/fossil merge --debug away
> N=3 0e060d1e500398f692088acff2981a1ea57b1bde
> P=19 ed49365cd035e7eaadf99ba315bf211e75a915b6
> M=21 48a07754f9c0bcbe0d4408e9a83c976ae74c8b85
> V=19 ed49365cd035e7eaadf99ba315bf211e75a915b6
>
> add_renames for fn
>
> add_renames for fnp
> N->M at 14> 4386173c7f: 2[afile] -> 0[]
> N->M at 14> 4386173c7f: 2[afile] -> 3[Afile]
> N->M summary 2[afile] -> 3[Afile]
>
> add_renames for fnm
> 1: ridv=0ridp=0ridm=0idv=0idp=0idm=0chnged=0
> isexe=0 islinkv=0 islinkm=0
> fn = []
> fnp = []
> fnm = [Afile]
> fnn = [afile]
>
> add files found in V
> 1: ridv=0ridp=0ridm=0idv=0idp=0idm=0chnged=0
> isexe=0 islinkv=0 islinkm=0
> fn = [afile]
> fnp = []
> fnm = [Afile]
> fnn = [afile]
> 2: ridv=12 ridp=0ridm=0idv=9idp=0idm=0chnged=0
> isexe=0 islinkv=0 islinkm=0
> fn = [Afile]
> fnp = []
> fnm = []
> fnn = []
> 3: ridv=18 ridp=0ridm=0idv=10 idp=0idm=0chnged=0
> isexe=0 islinkv=0 islinkm=0
> fn = [file]
> fnp = []
> fnm = []
> fnn = []
>
> add files found in P
> 1: ridv=0ridp=0ridm=0idv=0idp=0idm=0chnged=0
> isexe=0 islinkv=0 islinkm=0
> fn = [afile]
> fnp = [afile]
> fnm = [Afile]
> fnn = [afile]
> 2: ridv=12 ridp=0ridm=0idv=9idp=0idm=0chnged=0
> isexe=0 islinkv=0 islinkm=0
> fn = [Afile]
> fnp = [Afile]
> fnm = []
> fnn = []
> 3: ridv=18 ridp=0ridm=0idv=10 idp=0idm=0chnged=0
> isexe=0 islinkv=0 islinkm=0
> fn = [file]
> fnp = [file]
> fnm
Re: [fossil-dev] SQLITE_CONSTRAINT: abort at 41
Thus said Zakero on Sun, 16 Oct 2016 18:45:41 -0500:
> Ran into an interesting problem yesterday when merging branches:
>
> SQLITE_CONSTRAINT: abort at 41 in [INSERT INTO
> vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
> 21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735]: UNIQUE
> constraint failed: vfile.pathname, vfile.
> fossil: UNIQUE constraint failed: vfile.pathname, vfile.vid: {INSERT INTO
> vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
> 21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735}
> Rolling back prior filesystem changes...
I have been working with Zakero on this problem, but so far have been
unable to provide a suitable fix, mostly because I'm not sure which part
of the code is actually the cause of the problem; that and and lack of
familiarity with the merge algorithm (is there one?) and code.
I have finally been able to reproduce this problem with a minimal
test-case. I will include the output below that can trigger the problem.
I've added some additional uncommitted debug code to Fossil to help
understand what's happening; basically just output the fv table after
each modification to it. I believe the problem happens because the same
file is attempted to be added to the vfile table due to failure to
detect that there was a rename.
In the debug, you'll notice that Fossil first adds in renames for fn,
and there are none, so there is no output. Then it adds in renames for
fnp (Pivot) and there are some but none that get added to fv. Then it
adds in renames for fnm (Merge) and finally there is an entry in the fv
table for a change from the name pivot (N) to the merge version (M).
afile is recorded as renamed to Afile due to the merge.
Next, Fossil starts adding in files from the checkout version (V) and
another row is added to the fv table for the rename. Should it have
updated the existing entry in fv? Or should it be handled later on with
the rest of the code that checks for various renames?
Moving on...
After adding files from V, both row 1 and row 2 in fv that represent
changes to Afile. Adding in files from P updates both rows 1 and 2.
Adding in files from M doesn't alter row 1 or 2, but does update row 3
(un unrelated file). No further modifications are made to fv and in the
end, when Fossil begins updating the vfile table, it ends up trying to
insert the same filename twice but for different reasons.
I've tried what I thought would be an appropriate fix, but there were a
handful of failures in merge5, merge_renames and one in merge_exe, so
either it was the wrong fix, or the tests are biased towards incorrect
behavior.
Here is the enhanced merge debug output:
$ /tmp/fossil merge --debug away
N=3 0e060d1e500398f692088acff2981a1ea57b1bde
P=19 ed49365cd035e7eaadf99ba315bf211e75a915b6
M=21 48a07754f9c0bcbe0d4408e9a83c976ae74c8b85
V=19 ed49365cd035e7eaadf99ba315bf211e75a915b6
add_renames for fn
add_renames for fnp
N->M at 14> 4386173c7f: 2[afile] -> 0[]
N->M at 14> 4386173c7f: 2[afile] -> 3[Afile]
N->M summary 2[afile] -> 3[Afile]
add_renames for fnm
1: ridv=0ridp=0ridm=0idv=0idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = []
fnp = []
fnm = [Afile]
fnn = [afile]
add files found in V
1: ridv=0ridp=0ridm=0idv=0idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [afile]
fnp = []
fnm = [Afile]
fnn = [afile]
2: ridv=12 ridp=0ridm=0idv=9idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [Afile]
fnp = []
fnm = []
fnn = []
3: ridv=18 ridp=0ridm=0idv=10 idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [file]
fnp = []
fnm = []
fnn = []
add files found in P
1: ridv=0ridp=0ridm=0idv=0idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [afile]
fnp = [afile]
fnm = [Afile]
fnn = [afile]
2: ridv=12 ridp=0ridm=0idv=9idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [Afile]
fnp = [Afile]
fnm = []
fnn = []
3: ridv=18 ridp=0ridm=0idv=10 idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [file]
fnp = [file]
fnm = []
fnn = []
add files found in M
1: ridv=0ridp=0ridm=0idv=0idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [afile]
fnp = [afile]
fnm = [Afile]
fnn = [afile]
2: ridv=12 ridp=0ridm=0idv=9idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [Afile]
fnp = [Afile]
fnm = []
fnn = []
3: ridv=18 ridp=0ridm=0idv=10 idp=0idm=0chnged=0 isexe=0
islinkv=0 islinkm=0
fn = [file]
fnp = [file]
fnm = [file]
fnn = []
compute file version ids for P and M
1: ridv=0ridp=0ridm=0i
Re: [fossil-dev] SQLITE_CONSTRAINT: abort at 41
Thus said Zakero on Sun, 16 Oct 2016 18:45:41 -0500:
> SQLITE_CONSTRAINT: abort at 41 in [INSERT INTO
> vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
> 21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735]: UNIQUE
> constraint failed: vfile.pathname, vfile.
> fossil: UNIQUE constraint failed: vfile.pathname, vfile.vid: {INSERT INTO
> vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
> 21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735}
> Rolling back prior filesystem changes...
Can you provide steps to reproduce this, or otherwise provide a link to
the Fossil so that it can be attempted by others?
From the error, it seems to be a problem with your local checkout. What
happens if you clone again from the original source, and then attempt
the merge?
Thanks,
Andy
--
TAI64 timestamp: 40005804421e
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
[fossil-dev] SQLITE_CONSTRAINT: abort at 41
Greetings Everyone!
Ran into an interesting problem yesterday when merging branches:
SQLITE_CONSTRAINT: abort at 41 in [INSERT INTO
vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735]: UNIQUE
constraint failed: vfile.pathname, vfile.
fossil: UNIQUE constraint failed: vfile.pathname, vfile.vid: {INSERT INTO
vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname) SELECT
21178,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=4735}
Rolling back prior filesystem changes...
This was using Fossil 1.35 from the download page on the website. I also
downloaded the source from the latest check-in at the time (
http://fossil-scm.org/index.html/info/b2d51b1b226d2a50). And the problem
still exists. I also tried rebuilding the repository and no luck.
There have been similar messages on the mailing lists in the past, but I
did not see any resolutions:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05786.html
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23568.html
I am using Linux, openSuSE Tumbleweed 64-bt, the output of "fossil version
-v" is:
This is fossil version 1.36 [b2d51b1b22] 2016-10-16 01:21:34 UTC
Compiled on Oct 16 2016 18:18:00 using gcc-6.2.1 20160830 [gcc-6-branch
revision 239856] (64-bit)
SQLite 3.15.0 2016-10-14 10:20:30 707875582f
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2j-fips 26 Sep 2016)
UNICODE_COMMAND_LINE
DYNAMIC_BUILD
Does anyone have any suggestions or tips?
Thanks in advance for any help :-)
Zakero
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
