Re: [fossil-dev] Fossil 2.0 and mv/rm behaviour

[Baruch Burstein]

This is what happened as I understand it:

The codename "fossil 2.0" has been used for a few years whenever a change
that would potentially break backwards compatibility was suggested. Such a
version, if ever released, would require more planning, more testing and
more notice to users then a "regular" cycle release. Since the SHA1 issue
caught everyone by surprise (side note: Why were we all caught by surprise
when this was known to be theoretically possible for over a decade?), there
was an urgent need to fix this issue, which would break backwards
compatibility. So "fossil 2.0" happened in a rush, without time to track
down and implement all the issues waiting for "fossil 2.0".

-- END HISTORY LESSON --

That being said, time for my suggestion: Since version 2.0 ended up NOT
breaking anything, and the breaking changes will be in 2.1 and 2.2, maybe
we can still change some of the things that were waiting for a "breaking"
release in 2.1 or 2.2? Since the SHA1 issue will not really be fixed until
version 2.1, but version 2.2 will still be breaking some backwards
compatibility (pushing from a pre-2.1 client will not be possible) , how
about releasing 2.1 with only a note in the release notes that this will be
the last version with behaviors X, Y and Z, and then take the time for 2.2
to actually implement/change what is needed?

-- 
˙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 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...

[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

[fossil-dev] Fwd: miniz (Re: Branches in need of merging...)

[Baruch Burstein]

This is the conversation I had with the miniz developer

Forwarded conversation
Subject: miniz


From: *Baruch Burstein* <bmburst...@gmail.com>
Date: Wed, Feb 3, 2016 at 10:14 AM
To: richge...@gmail.com


Hi,

I think miniz is really useful, and even incorporated it into fossil scm.
It is marked as 1.16 BETA - will it still be updated? Google code has been
shut down for a while now, but miniz still doesn't seem to have a new home.
Does this mean you are not upkeeping this anymore?

Thank you,
Baruch

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

--
From: *Rich Geldreich* <richge...@gmail.com>
Date: Wed, Feb 3, 2016 at 10:41 PM
To: Baruch Burstein <bmburst...@gmail.com>


Hi Baruch - miniz lives on github here:
https://github.com/richgel999/miniz

But this version is basically what was on Google Code. I have 1-2 bug fixes
to merge in when I get a chance. I've been slammed with other work
recently, so I don't get to work on it a whole lot. However, miniz is very
much still alive.

Best regards,
-Rich


------
From: *Baruch Burstein* <bmburst...@gmail.com>
Date: Wed, Feb 3, 2016 at 11:50 PM
To: Rich Geldreich <richge...@gmail.com>


Thanks. The github version seems to be older than the GC one. 1.16a > 1.15r4




-- 
˙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

[fossil-dev] Request for merge

[Baruch Burstein]

I would like to propose these branches be merged into trunk:

https://www.fossil-scm.org/index.html/info/cfd3a5b944ea15f4 -
Fixes the behavior of the Older/Newer buttons in the case of showing
timeline past the end. Example:
https://www.fossil-scm.org/index.html/timeline?n=50=ci=2006-01-30+00:43:48
,
https://www.fossil-scm.org/index.html/timeline?a=2023-09-04+19:17:27=50=ci
Fixes the display of Older/Newer buttons in case of timeline exactly up to
first/last event. Can be seen by going to the timeline and pressing older
followed by newer. There will still be a newer button.
Fixes the behavior of the Newer button when using the "c" parameter
(Example:
https://www.fossil-scm.org/index.html/timeline?c=938122da85336d15)

https://www.fossil-scm.org/index.html/info/50d81f95041f631e

https://www.fossil-scm.org/index.html/info/26fc65f99c035dac



-- 
˙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] updated miniz.c

[Baruch Burstein]

On Thu, Feb 4, 2016 at 10:43 AM, Stephan Beal  wrote:

> On Thu, Feb 4, 2016 at 9:04 AM, Stephan Beal 
> wrote:
>
>> Interestingly, that repo "only" has 1.15, not the 1.16 i scrounged up
>> (which i've since locally patched for a few portability problems).
>>
>
> Latest commit 28f5066
> 
>  on Oct 14, 2013
>
> He's also been silent on all tickets/pull requests, and hasn't responded
> to emails from me.
>
> It's not clear whether he's still around or not. The last commits shown in
> his github profile are from November.
>

He responded to my email last night. That is how I found the github page.
He claimed that miniz is still alive, he hasn't had much time to work on
it, and he has plans to fix a few issues when he gets time.



-- 
˙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] updated miniz.c

[Baruch Burstein]

On Tue, Feb 2, 2016 at 5:59 PM, Stephan Beal  wrote:

> Hi, all,
>
> The original miniz site was gcode and it's long since been turned off. i
> have been unable to find a current official home for it
>

https://github.com/richgel999/miniz



-- 
˙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] pending-review: removal of fuse code when built w/o fuse

[Baruch Burstein]

On Thu, Jan 21, 2016 at 4:39 PM, Richard Hipp <d...@sqlite.org> wrote:

> On 1/21/16, Baruch Burstein <bmburst...@gmail.com> wrote:
> >
> > If fossil is compiled without fuse
> > support, ... It also
> > shouldn't show up in the listing of "fossil help".
>
> That could be fixed (probably) by omitting "fusefs" from the "fossil
> help" listing on systems where fusefs is not supported, just as
> commands like "cgi" and "artifact" and "zip" are currently omitted
> from "fossil help" (unless you include the --all option).


That would be good, too.
Is there any special reason not to treat fusefs the same as json (which is
completely removed if compiled without json support, and "fossil json"
gives "command not found" and not "not implemented in this build")?

-- 
˙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] pending-review: removal of fuse code when built w/o fuse

[Baruch Burstein]

On Thu, Jan 21, 2016 at 3:16 PM, Richard Hipp  wrote:

> On 1/21/16, Stephan Beal  wrote:
> > Hiho,
> >
> > since this is pending review...
> >
> > http://www.fossil-scm.org/index.html/info/06fd798bdcb9da50
> >
> > FYI: that won't compile properly on some systems because C does not allow
> > an empty compilation unit, which is what that amounts to when fuse is
> > disabled.
>

This is easily solved by moving the #ifdef to below the #includes


> I tried to merge it yesterday, but it gave problems.  In particular I
> got "command not found" when I ran "fossil fuse" rather than "not
> implemented in this build", which I do not think is an improvement.


While I obviously don't have the final say on what gets merged to trunk, I
would like to try defend my case. If fossil is compiled without fuse
support, nobody should be running the fuse command with it. It also
shouldn't show up in the listing of "fossil help".  As a fossil user on
Windows, I find the "fusefs" option listed in the output of "fossil help"
akin to annoying noise. The same way that if fossil is compiled without
JSON support than it doesn't even include the "fossil json" command.

-- 
˙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

[fossil-dev] Close old branch

[Baruch Burstein]

Can https://www.fossil-scm.org/index.html/info/3baa7e3dc195a888 be closed?
I would assume so, but am not at all familiar with the TH1/test areas of
the code and so would rather not do it on my own.

-- 
˙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] Check-in etiquette

[Baruch Burstein]

On Thu, Aug 27, 2015 at 11:15 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:


 Joe already correct that:
 http://www.fossil-scm.org/index.html/info/e947fce957171e44


I saw that (thanks from me too).I was wondering for future times.

The only potential problem: people might wonder how you tested
 the change.


I made the change locally in my makefile and used it. I then made the same
change in the tcl script and committed that one.
I guess I could have just committed my hand-changed makefile.

-- 
˙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] Can't clone

[Baruch Burstein]

On Wed, Aug 26, 2015 at 12:12 PM, Thomas Schnurrenberger t...@gmx.net
wrote:

 On 26.08.2015 10:33, Baruch Burstein wrote:

 Hi,
 When I try to clone the fossil repo from https://fossil-scm.org, I get an
 error that the SSL certificate is for sqlite.org. I also get this error
 when browsing to https://fossil-scm.org. Is this a configuration error?

 The certificate viewer in Firefox shows, that the SSL certificate
 is valid for www.fossil-scm.org. What happens if you try to clone
 with https://www.fossil-scm.org?


That solves the error in the browser, but still not for the clone.


-- 
˙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

[fossil-dev] Can't clone

[Baruch Burstein]

Hi,
When I try to clone the fossil repo from https://fossil-scm.org, I get an
error that the SSL certificate is for sqlite.org. I also get this error
when browsing to https://fossil-scm.org. Is this a configuration error?

Baruch

-- 
˙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