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.
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
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
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.
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 @@
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
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
___
7 matches
Mail list logo