Re: [fossil-users] Objections to merging stash-fixes branch?

2016-09-07 Thread Joe Mistachkin

Andy Bradford wrote:
>
> Any objections to merging the stash-fixes branch?
> 

Andy,

FYI, I've modified your branch to re-merge changes from trunk without
the changes for OpenSSL 1.1.0, which is not quite ready for primetime
yet.

Jan, 

I think the MSVC makefile needs updating for the OpenSSL 1.1.0 changes
to work.  Also, maybe we should wait for 1.1.0 to mature a bit prior
to migrating Fossil to it?  Technically, their 1.0.2 branch is still
listed as "stable" and "supported" (until 2019-12-31).

--
Joe Mistachkin @ https://urn.to/r/mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] Objections to merging stash-fixes branch?

2016-09-07 Thread Andy Bradford
Hello,

Any objections to merging the stash-fixes branch?

Basically, by changing the primary key,  it is possible to track renames
in a stash:

http://www.fossil-scm.org/index.html/vdiff?from=b03f15635dd356be=1912b2f864a746bb=1

In addition to  creating a new schema for new  checkouts, it will detect
and change the schema of the  stashfile table in an existing checkout so
it  isn't necessary  to close  and reopen  the checkout  to get  the new
schema.

Thanks,

Andy
-- 
TAI64 timestamp: 400057d0c999


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-07 Thread Ross Berteig

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 tested branch-1.35 with MinGW and MSYS on Windows 10 Pro 
using the zlib from the tree with and without SSL support. Exactly two 
test cases report failures: merge-utf-79-23 and merge-utf-79-32. Nearly 
all released versions of fossil I've examined have a similar pair of 
failed test cases.


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.


On the pair of failed tests: nearly all released versions of fossil have 
failed a trial of the merge-utf-*-{23,32} cases. This is a family of 
merge tests built using source files drawn from the fossil test suite 
itself, which are hammered with random edits, merged, and validated. The 
use of the random number generator fuzzes through a lot of cases. 
Today's failure is the 79th fuzzing of utf.test. I strongly suspect that 
this exposes an edge case in the merge logic when dealing with (likely) 
broken UTF characters in one or more of the changes being merged.


Figuring out what is really going on there has been on my back burner 
for a while now, I may have to give in to curiosity (despite what that 
does to cats) and try to understand it one of these days.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-07 Thread Jan Nijtmans
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 why I used UNION ALL there, but it's definitely
> wrong.

Well, I noticed the lock-up as well, some weeks ago but didn't
bother to dig into it because I could do what I wanted to
do by merging the other way. Glad that it's fixed now! Thanks!

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.

Regards,
 Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users