Re: [fossil-dev] Branches in need of merging...

[Baruch Burstein]

On Fri, Mar 11, 2016 at 6:52 AM, Joe Mistachkin  wrote:

>
> By my estimation, there are around 7 branches (nearly?) ready to be merged.
> I've
> briefly looked over the changes; however, it would be good if others could
> review
> and/or provide feedback on them as well.
>
> --
> Joe Mistachkin
>

Some of these branches were merged, others were closed, and some are still
waiting to go one way or the other while this seems to have stalled. It
would be nice to close a few more of them, one way or another. I am
obviously pushing for inclusion of my two changes ([ff4a] and 4bd2], both
minor IMO), but would appreciate it even if they were declared "wont merge"
and closed. The other ones would also be nice to make a final decision on
(assuming they are "done").

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[David Vines]

On 14/03/2016 18:42, David Vines wrote:



Thanks for the feedback - I was thinking that some testcases would
definitely make sense - I'll  start on those while we see if there's a
consensus and whether that will require changes to the implementation...



The technote-cli branch can be closed (its contents are in 
technoteattachcli).


I have created a wiki.test test suite to exercise the command interface 
for tech notes and attachments, but don't have write access to the 
fossil repository - is there someone to whom I can send the test suite?


Dave

___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[Ross Berteig]

On 3/18/2016 1:20 AM, David Vines wrote:

On 14/03/2016 18:42, David Vines wrote:

Thanks for the feedback - I was thinking that some testcases would
definitely make sense - I'll  start on those while we see if there's a
consensus and whether that will require changes to the implementation...


The technote-cli branch can be closed (its contents are in
technoteattachcli).


Done.


I have created a wiki.test test suite to exercise the command interface
for tech notes and attachments, but don't have write access to the
fossil repository - is there someone to whom I can send the test suite?


You can send it to me at the email address in my sig block, but you did 
have write access to the repo last December and January, as either djv 
or dave.vines. At least there are checkins then with those names that I 
assume are you.


If you've lost your password, someone with more access than I have will 
need to intervene, but I'm sure that can be done.


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

Re: [fossil-dev] Branches in need of merging...

[David Vines]

On 13/03/2016 23:58, Ross Berteig wrote:


On 3/13/2016 4:24 AM, David Vines wrote:

On 11/03/2016 22:49, Ross Berteig wrote:


* technoteattachcli

New fossil attach command for CLI ability to attach files to wiki pages
and technotes. Work in progress, apparently stalled.

* technote-cli

New CLI features for managing technotes. Work in progress, apparently
stalled.


Looking more closely, it appears that the changes in technnote-cli got
made a second time in the branch technoteattach, which was integrated to
trunk by Richard right before you branched off technoteattachcli. Since
my survey was only of open branches, I missed that one.


I've haven't any comments back on these branches, but I'm happy with the
version of fossil I'm running with these branches (my implementation
certainly does the job I want to do), I haven't followed up. I don't
think a novice (with fossil) should be merging them in any event :). Any
thoughts as to my next actions?


IMHO, aside from checking if there's any part of the changes made in
technote-cli that got missed in the later branch, it likely should
simply be closed and abandoned.

That leaves technoteattachcli as the home of some further changes,
notably the new fossil attachment command to support attaching files to
wiki pages and technotes from the CLI. Which is certainly a useful feature.

Since there's been a fair bit of change on trunk since the first of the
year, the next step is to  merge trunk into the your branch and resolve
any quirks and issues that creates. That will get you the latest round
of improvements to the test framework as well.

Since this step doesn't require particular knowledge of your new
features, I have done that merge, built it on Windows, and note that it
passes all the test cases that currently exist.

There's currently no test coverage at all of the old wiki command, and
certainly no coverage of the new --technote option or the attachment
command. I'd like to encourage new features to have at least a minimal
test case that exercises their basic functions. If I have time, I'll see
what I can do for that as well.

Aside from test cases, I guess we need consensus that the new fossil
attachment command is the right way to add the feature. It makes sense
to me. Anyone else want to chime in?



Thanks for the feedback - I was thinking that some testcases would 
definitely make sense - I'll  start on those while we see if there's a 
consensus and whether that will require changes to the implementation...


Dave
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[Ross Berteig]

On 3/13/2016 4:24 AM, David Vines wrote:

On 11/03/2016 22:49, Ross Berteig wrote:


* technoteattachcli

New fossil attach command for CLI ability to attach files to wiki pages
and technotes. Work in progress, apparently stalled.

* technote-cli

New CLI features for managing technotes. Work in progress, apparently
stalled.


Looking more closely, it appears that the changes in technnote-cli got 
made a second time in the branch technoteattach, which was integrated to 
trunk by Richard right before you branched off technoteattachcli. Since 
my survey was only of open branches, I missed that one.



I've haven't any comments back on these branches, but I'm happy with the
version of fossil I'm running with these branches (my implementation
certainly does the job I want to do), I haven't followed up. I don't
think a novice (with fossil) should be merging them in any event :). Any
thoughts as to my next actions?


IMHO, aside from checking if there's any part of the changes made in 
technote-cli that got missed in the later branch, it likely should 
simply be closed and abandoned.


That leaves technoteattachcli as the home of some further changes, 
notably the new fossil attachment command to support attaching files to 
wiki pages and technotes from the CLI. Which is certainly a useful feature.


Since there's been a fair bit of change on trunk since the first of the 
year, the next step is to  merge trunk into the your branch and resolve 
any quirks and issues that creates. That will get you the latest round 
of improvements to the test framework as well.


Since this step doesn't require particular knowledge of your new 
features, I have done that merge, built it on Windows, and note that it 
passes all the test cases that currently exist.


There's currently no test coverage at all of the old wiki command, and 
certainly no coverage of the new --technote option or the attachment 
command. I'd like to encourage new features to have at least a minimal 
test case that exercises their basic functions. If I have time, I'll see 
what I can do for that as well.


Aside from test cases, I guess we need consensus that the new fossil 
attachment command is the right way to add the feature. It makes sense 
to me. Anyone else want to chime in?


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

Re: [fossil-dev] Branches in need of merging...

[Ross Berteig]

On 3/12/2016 11:45 PM, Baruch Burstein wrote:

On Sat, Mar 12, 2016 at 2:27 AM, Ross Berteig  wrote:
On 3/11/2016 3:40 PM, Joe Mistachkin wrote:

I don't feel strongly about gone or not, but consistent would be
good. IIRC there was some resistance to the original version of this
change where it was totally gone, and the current state where fusefs
became a secondary command that fails was the result of that.

https://www.mail-archive.com/fossil-dev%40mailinglists.sqlite.org/msg00374.html


That email thread seems to imply a preference from drh in particular 
(and others too) for keeping the fossil fusefs command but demoting it 
to the help -a list when not configured. With a strong implication that 
the current implementation of fossil json is thus wrong.


I've personally never used the fusefs support, but I do wonder if the 
command shouldn't *always* be demoted to the help -a list. Is it really 
the sort of command that is used every day by novice users?


Perhaps we should do that for fossil json now, and I think the same 
argument about help -a applies. I'll poke at that, see what pokes back.




[snip]

* baruch_timeline_fixes

I thought I remembered some discussion, but my google-fu is failing
me today. The obvious test of just loading /timeline in fossil ui
and clicking older and newer worked. I didn't poke at it much more
than that.

https://www.mail-archive.com/fossil-dev%40mailinglists.sqlite.org/msg00419.html


Thanks for the pointer. I built and tested this again, and now that I 
see what it is doing it all looks great. I'm merging it to trunk now.



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

Re: [fossil-dev] Branches in need of merging...

[Baruch Burstein]

On Sat, Mar 12, 2016 at 10:24 AM, Stephan Beal 
wrote:

> On Sat, Mar 12, 2016 at 12:40 AM, Joe Mistachkin 
> wrote:
>
>> >
>> > * miniz-1.16br1
>> >
>> > IMHO, if any library we fold in to our source tree has updates, we
>> > should evaluate them. Miniz certainly fits that description, the
>> > question may be where the official upstream source is located post
>> > google-code's closure.
>> >
>>
>> Yes, if we are going to retain support for it, it needs to be up-to-date
>> (especially it appears to have some issues that zlib does not have).
>>
>> However, before updating it, we really need to find its official source.
>>
>> If it's no longer actively maintained, we should probably just remove it
>> from the tree.
>>
>
> Someone (Baruch?) posted a link to the now-official github site, but
> AFAICS it's not actively maintained. i mailed the guy a couple of times
> with C89 portability patches and got no response, but IIRC Baruch reported
> getting a response from him.
>
> In any case, i tend to agree - if it's not maintained, we should drop it
> because it's not a piece "just anyone" can get their fingers in and tweak
>

I forwarded my conversation with him to this list. If anyone wants to take
it up from there...


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[Baruch Burstein]

On Sat, Mar 12, 2016 at 2:27 AM, Ross Berteig  wrote:

>
>
> On 3/11/2016 3:40 PM, Joe Mistachkin wrote:
>
>>
>> Ross Berteig wrote:
>>
>>>
>>>
>>> * [ff4a] pending-review
>>>
>>> IMHO, merge this.
>>>
>>> Changes how the fusefs command appears when fossil is compiled without
>>> fusefs included. Seems reasonable. In fact, I wonder if the json command
>>> shouldn't get a similar treatment when json is not enabled.
>>>
>>>
>> It would be nice if we could be consistent in this area.  If a feature is
>> not included in the build, it should ideally be totally gone.
>>
>
> I don't feel strongly about gone or not, but consistent would be good.
> IIRC there was some resistance to the original version of this change where
> it was totally gone, and the current state where fusefs became a secondary
> command that fails was the result of that.


https://www.mail-archive.com/fossil-dev%40mailinglists.sqlite.org/msg00374.html


[snip]


>>> * baruch_timeline_fixes
>>>
>>> Builds on Windows. A quick scan of the source changes doesn't look like
>>> trouble. /timeline and its buttons seem to work, but I haven't located a
>>> test case to evaluate this change.
>>>
>>>
>> There is a test case somewhere.  I think it may have been posted to the
>> mailing list(s) at some point.  I don't quite know enough about that code
>> to be 100% confident in the changes.
>>
>>
> I thought I remembered some discussion, but my google-fu is failing me
> today. The obvious test of just loading /timeline in fossil ui and clicking
> older and newer worked. I didn't poke at it much more than that.


https://www.mail-archive.com/fossil-dev%40mailinglists.sqlite.org/msg00419.html

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[Ross Berteig]

On 3/12/2016 2:10 PM, Joe Mistachkin wrote:

Ross Berteig wrote:

It also led me to blog posts from miniz's author. He does seem to
still be alive, but miniz may be dormant.

Do you have a direct link to the authors blog (I don't think the
"cbloomrants" is it)?  Can we get somebody to ping him and see if he's
still interested in maintaining miniz (or passing it off to somebody
else to maintain it)?


From what I found he's blogging at http://richg42.blogspot.com/

I got there from this post:

http://richg42.blogspot.com/2015/12/one-test-showing-performance-of-miniz.html

where he writes "miniz (was here[1], now migrating to github here[2]) is 
my single source file zlib-alternative".


[1]: https://code.google.com/p/miniz/
[2]: https://github.com/richgel999/miniz

It does look like the last commit on the github was two years ago, and 
there are open issues. I didn't try to evaluate how critical any of them 
are. Yet.



I would really like to retain miniz support.  However, if it becomes
necessary to remove it, I've put the necessary changes (to completely
remove it) on a branch.


It looks like a nice clean implementation. I've been using fossil built 
from it for some time now without issue. If I needed a simple to 
integrate compressor, it would be high on my list of candidates.


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

Re: [fossil-dev] Branches in need of merging...

[Joe Mistachkin]

Ross Berteig wrote:
>
> It also led me to blog posts from miniz's author. He does seem to
> still be alive, but miniz may be dormant.
> 

Do you have a direct link to the authors blog (I don't think the
"cbloomrants" is it)?  Can we get somebody to ping him and see if he's
still interested in maintaining miniz (or passing it off to somebody
else to maintain it)?

I would really like to retain miniz support.  However, if it becomes
necessary to remove it, I've put the necessary changes (to completely
remove it) on a branch.

--
Joe Mistachkin

___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[Ross Berteig]

On 3/12/2016 12:24 AM, Stephan Beal wrote:

Someone (Baruch?) posted a link to the now-official github site, but
AFAICS it's not actively maintained. i mailed the guy a couple of times
with C89 portability patches and got no response, but IIRC Baruch
reported getting a response from him.

In any case, i tend to agree - if it's not maintained, we should drop it
because it's not a piece "just anyone" can get their fingers in and tweak.


Googling around led me to this interesting study of raw performance of a 
handful of compression libraries, including both miniz and zlib. 
Interestingly, they are dead tied in these benchmarks. I haven't looked 
too carefully, but I think this was a survey of the compression field, 
not restricted to libraries producing zlib-compatible bitstreams or 
restricted to matching the zlib API.


http://cbloomrants.blogspot.com/2012/09/09-15-12-some-compression-comparison.html

It also led me to blog posts from miniz's author. He does seem to still 
be alive, but miniz may be dormant. He does seem to still be very 
interesting in compression. Here's a recent post making a startling 
claim. I haven't studied his argument carefully yet, but he drew pretty 
pictures from the data and I love cool data viz pr0n...


http://richg42.blogspot.com/2016/01/zlib-in-serious-danger-of-becoming.html

This is all an aside and distraction. I'm not convinced that fossil 
benefits particularly from anything less than a radical improvement in 
compression ratio, and likely hardly at all from compression speed.


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

Re: [fossil-dev] Branches in need of merging...

[Stephan Beal]

On Sat, Mar 12, 2016 at 12:40 AM, Joe Mistachkin 
wrote:

> >
> > * miniz-1.16br1
> >
> > IMHO, if any library we fold in to our source tree has updates, we
> > should evaluate them. Miniz certainly fits that description, the
> > question may be where the official upstream source is located post
> > google-code's closure.
> >
>
> Yes, if we are going to retain support for it, it needs to be up-to-date
> (especially it appears to have some issues that zlib does not have).
>
> However, before updating it, we really need to find its official source.
>
> If it's no longer actively maintained, we should probably just remove it
> from the tree.
>

Someone (Baruch?) posted a link to the now-official github site, but AFAICS
it's not actively maintained. i mailed the guy a couple of times with C89
portability patches and got no response, but IIRC Baruch reported getting a
response from him.

In any case, i tend to agree - if it's not maintained, we should drop it
because it's not a piece "just anyone" can get their fingers in and tweak.
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[Jan Danielsson]

On 11/03/16 23:49, Ross Berteig wrote:
[---]
> * jan-manifest-tags
> 
> New feature to generate a file containing a list of the tags on the
> current checkout for the benefit of build and release tooling, suggested
> and mostly implemented by Jan Danielsson:
> 
> http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg22317.html
> 
> 
> It seems to have proceeded well past proof-of-concept, then stalled.

   The status on this is that it's more or less finished in the sense that:
   -  It can be used for what I originally set out to accomplish
(creates manifest.tags on request).
   -  manifest.tags is included when generating source archives.
   -  I haven't found any cases where the manifest.tags isn't updated as
intended (but it would be neat if others could take a look at it).
   -  It's non-intrusive (people who don't want to use the feature will
never notice the change).

   Perhaps I have forgotten something, but the remaining change I'd like
to do is per a request from Steve Stefanovich
(http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg22337.html).
 Unfortunately I have been involved in a new project which has left me
with very limited time.

   I'll try to find some time to finish this next weekend or so.

-- 
Kind Regards,
Jan
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

[Andy Bradford]

Thus said "Joe Mistachkin" on Thu, 10 Mar 2016 19:52:08 -0800:

> I've briefly  looked over the  changes; however,  it would be  good if
> others could review and/or provide feedback on them as well.

After some discussion with Ross, I  think there may be some improvements
that could  be made in the  stash-fixes branch which I  intend on making
when I have some free time.

Specifically,  having the  stashfile table  altered to  support the  new
schema automatically without requiring a  user to ``fossil close'' their
repository.

Andy
-- 
TAI64 timestamp: 400056e2545a


___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev