Re: [fossil-dev] Testing fossil 2.1

2017-03-13 Thread Ross Berteig
On 3/13/2017 5:17 PM, Richard Hipp wrote: I think the best solution here would be to change the RE to be "([0-9a-f]{40,64})". Does that fix the problem? That improves things, and moves to a new problem. A number of commands (sensibly) trim their output to a 40-character prefix of the UUID. S

Re: [fossil-dev] Testing fossil 2.1

2017-03-13 Thread Warren Young
On Mar 13, 2017, at 6:13 PM, Richard Hipp wrote: > > On 3/13/17, Ross Berteig wrote: >> I seem to have the test suite bee in my bonnet this week. > > I, for one, am hoping that bee hangs around :-) Can we get him a hat of office or something? :) ___

Re: [fossil-dev] Testing fossil 2.1

2017-03-13 Thread Richard Hipp
On 3/13/17, Ross Berteig wrote: > > proc uuid_from_commit {res var} { >upvar $var UUID >regexp {^New_Version: ([0-9a-f]{40})$} $res m UUID > } > > That regexp is clearly seeking a UUID exactly 40 characters long. I think the best solution here would be to change the RE to be "([0-9a-f]{40

Re: [fossil-dev] Testing fossil 2.1

2017-03-13 Thread Richard Hipp
On 3/13/17, Ross Berteig wrote: > I seem to have the test suite bee in my bonnet this week. I, for one, am hoping that bee hangs around :-) It's ok to do your test debugging on trunk, if you want to go ahead and merge your branch. -- D. Richard Hipp d...@sqlite.org

[fossil-dev] Testing fossil 2.1

2017-03-13 Thread Ross Berteig
I seem to have the test suite bee in my bonnet this week. I'd like the suite to execute cleanly for fossil 2.1, which it no longer doesfor reasons related to SHA3. The most obvious case is that there are numerous spots in the test suite where command output is parsed to recover some hash value