2016-09-08 1:32 GMT+02:00 Ross Berteig:
> So my testing does not block releasing 1.35.1.
>
> I have no strong opinion about whether such an update is required, but the
> most recent regression does seem like it causes real problems if tripped
> over.
I agree, but it's not up to me to decide. Upcom
On 9/7/2016 1:15 AM, Jan Nijtmans wrote:
Would this be enough reason to do a quick 1.35.1 release? Two
regressions are already found plaguing 1.35 for situations
which worked fine in 1.34. Branch "branch-1.35" is ready,
the only thing missing there is updating changelog.wiki.
I built and t
2016-09-07 5:17 GMT+02:00 Joel Bruick:
> This is the right fix. It ensures that each commit is only added to the
> queue by the recursive SELECT once instead of an exponential number of times
> based on how many merge commits it finds along the way, which is what caused
> your problem. I don't know
Hi Andy,
On 9/6/2016 3:26 PM, Andy Goth wrote:
That seems to fix it. Thank you very much for the astonishingly fast
turnaround. There may be unintended consequences since we haven't
done much analysis yet, so I checked your change in on the
merge-rename-lockup branch pending further testing.
That seems to fix it. Thank you very much for the astonishingly fast
turnaround. There may be unintended consequences since we haven't done much
analysis yet, so I checked your change in on the merge-rename-lockup
branch pending further testing.
On Tue, Sep 6, 2016 at 2:20 PM, Richard Hipp wrote:
On 9/6/16, Andy Goth wrote:
>
> The repository is private, sorry, but I should be able to help with
> debugging.
>
Just a guess:
Index: src/merge.c
==
--- src/merge.c
+++ src/merge.c
@@ -395,11 +395,11 @@
}
if( zPivot ){
On 9/6/16, Andy Goth wrote:
> The latest trunk is broken (w.r.t. the merge in question), as is apparently
> everything starting with 41c2220934. Version 1.34 is good, as is the
> version immediately before 41c2220934. I see no reason to downgrade to
> anything before 1.34, since that's what I've b
The latest trunk is broken (w.r.t. the merge in question), as is apparently
everything starting with 41c2220934. Version 1.34 is good, as is the
version immediately before 41c2220934. I see no reason to downgrade to
anything before 1.34, since that's what I've been using successfully since
its rele
On 9/6/16, Andy Goth wrote:
>
> Today I upgraded from Fossil 1.34, and it
> looks like I'm going to have to switch back.
>
Try using trunk before you downgrade to 1.33 or 1.32.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-use
"f merge branch-name -baseline root:branch-name" is an infinite loop for me
since Fossil change 41c2220934, as determined by bisection. Version
4d1f2d302b (latest trunk) is bad too. Execution hangs up inside SQLite.
The check-in comment for 41c2220934 is "Improve the merge command's ability
to han
10 matches
Mail list logo