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] Proposed roadmap for Fossil 2.0

[Baruch Burstein]

On Mon, Feb 27, 2017 at 8:59 PM, Richard Hipp  wrote:

> The insight here is that SHA1 hash collisions never occur by accident.
> They are always the result of malice.  So shunning the artifacts
> involved is never a problem.
>

Isn't that what will already happen with the current version? If someone
tries to commit an artifact that has a SHA1 hash that is already in the
repo, fossil will assume it is the same artifact and not add the new one,
effectively shunning it.

However, I disagree with your assessment that it is always the result of
malice. While it is definitely not an accident, it could be intentional,
e.g. the recent WebKit SVN issue, where they wanted to add both PDFs from
the SHAttered.io example to their repo for use in their test suite.


-- 
˙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] Bash completion - need input

[Baruch Burstein]

I would like to have tab completion in bash for fossil. I committed (
https://www.fossil-scm.org/index.html/timeline?r=bash-completion) a change
that builds the completion script from the list of commands during the
mkindex step of the build. The issue with doing it this way is that it only
has the command names, not sub-commands or flags or parameters. If I want
to add all of those I see two options to do so:

1) I can come up with some clever way of embedding all of this information
into the help comment that proceeds each command. Then when the mkindex
program processes these comments it will extract the info and build the
script accordingly, similar to what is already done for the commands
themselves.
2) I can just write and maintain the file manually.

Any suggestions as to which to prefer?

-- 
˙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] Please review

[Baruch Burstein]

Please review https://www.fossil-scm.org/index.html/info/8ae790623c14ac5c.
The problem it fixes can be seen clearly on the current timeline
(permalink:
https://www.fossil-scm.org/index.html/timeline?n=50&y=ci&a=2016-10-20+17:04:46).
The only issue I still have is with
https://www.fossil-scm.org/index.html/timeline?n=21&v=0&y=ci&a=2016-10-24+21:54:24,
where the thin line comes out of the thick one. Not a major issue IMO.

-- 
˙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] Did we just hit the 10000 check-ins mark?

[Baruch Burstein]

I am having trouble figuring out how to get the exact number

-- 
˙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] Time to release version 1.36?

[Baruch Burstein]

On Sun, Oct 16, 2016 at 3:46 AM, Joe Mistachkin 
wrote:

>
> Prior to the release, there are several branches that I personally
> think should be included:
>
> nick.lloyd-git-interop
> stash-fixes
> th1Unversioned
> prjDesc
> seeEnhanced
> 4bd2b54592a08fe0 -- Improved background color handling.
>
> A couple of these branches are for important bug fixes.  A couple
> are minor enhancements to functionality.


I would like to add also 972dc1c632 - removing old menus, and
either 06fd798bdc or 50d81f9504 for either removing or hiding fusefs
command when it is not supported


-- 
˙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* 
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* 
Date: Wed, Feb 3, 2016 at 10:41 PM
To: Baruch Burstein 


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* 
Date: Wed, Feb 3, 2016 at 11:50 PM
To: Rich Geldreich 


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 suggest these branches for merging 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&y=ci&b=2006-01-30+00:43:48
,
https://www.fossil-scm.org/index.html/timeline?a=2023-09-04+19:17:27&n=50&y=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&unhide)

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

[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&y=ci&b=2006-01-30+00:43:48
,
https://www.fossil-scm.org/index.html/timeline?a=2023-09-04+19:17:27&n=50&y=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&unhide)

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  wrote:

> On 1/21/16, Baruch Burstein  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:

> So I left that proposal on its branch.


Since this was mentioned, I have a question about fossil development
etiquette. In the last couple of days, I have had some time and have made a
few fixes and (in my opinion) improvements. Each one is really a small
change that stands on its own. As you see in the timeline, my approach was
to put each one in a new branch, all named "pending-review", with the
description only in the commit message. I figured that that way they were
easy to accept or reject individually, were clearly marked as a small
change ready to merge, and if rejected can be closed so as not to keep
multiple open leafs with the same branch name for too long.
Is this approach bothersome since there are for a short time multiple leafs
of the same name? Would it be nicer to give each branch a unique name and
either tag them as ready-for-merge, or say so here?


-- 
˙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] [fossil-users] Additional information in Check-in Checklist

[Baruch Burstein]

On Tue, Nov 24, 2015 at 9:28 PM, Chad Clabaugh 
wrote:

> This is quite helpful. Thank you. I've subscribed to the dev list.
>
> I do think it could be helpful for others in the future if this info were
> mentioned somewhere in the contribution wiki.
>
> Thanks again,
> Chad
>

(moved to the dev list)

Since the fossil web site is part of the fossil repo, you are of course
welcome to write it up and commit it :)

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

>
> Joe already correct that:
> 
>

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

[fossil-dev] Check-in etiquette

[Baruch Burstein]

Hi,

I know that when making changes to makemake.tcl, I am expected to run the
script to generate the new makefiles and check them in as well. However, I
am on a computer where I cannot easily install TCL (company policy). I
committed the changes to makemake.tcl without regenerating the makefiles,
leaving that to someone else. Is this acceptable?

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

Re: [fossil-dev] Can't clone

[Baruch Burstein]

On Wed, Aug 26, 2015 at 12:12 PM, Thomas Schnurrenberger 
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

[fossil-dev] Idea for enhancement - test reports

[Baruch Burstein]

Here is an idea I was considering implementing if I ever get time to do it.
I am interested in hearing other's thoughts on the usefulness and
implementation of it.

The main point is to integrate a "test report" (or "status board" as it is
called in sqlite) into fossil. The rationale being that just like docs or
tickets are versioned along with the code since they are essentially part
of the state of the code at any specific revision (e.g. if I go back to an
older version, I would want the docs for that version and a list of known
issues with it, too), also tests passing/failing are part of this state.
Note that I am not suggesting adding a test runner that will automatically
fill the report, only the report itself.

My simplest idea for implementing this is to use the existing tags
mechanism. For the sake of the example I will use tag names test-*, but
this might not be the best choice in reality.
A new test would be added as a propagating tag such as "test-name=Compiles
without warnings". A link on the check-in page (maybe in the "Other Links"
line) will link to a list of tests (maybe like this
https://www.sqlite.org/checklists/3081100/index) with a list of all tests
(taken from the test-name tags) and an option to mark each as
passed/failed. A passed/failed test will be indicated as a non-propagating
tag such as "test-Compiles-without-warnings=pass".
A test-runner or CI system could write a simple file that is a control
artifact that adds the pass/fail tags as needed to the specific check-in
and adds this file to the fossil repo.
A drawback of this approach is that tags do not propagate across merges,
and I think it makes sense that if a test case is added to a branch, it
should propagate branches that it is merged into.

Another more complex approach would be to add a new type of artifact -  a
"Test artifact". Or maybe have the test cases as a new artifact but the
results as regular tags?

As you can see, this is only a half-baked idea. I would appreciate comments
both on the idea itself and on the implementation of it.

Thanks,
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

Re: [fossil-dev] svn-import branch

[Baruch Burstein]

On Thu, Feb 26, 2015 at 1:37 AM, Martin Gagnon  wrote:

> But if I understand well, on the first import, you need to use
> --incremental (even if it's the initial import) in order to be able
> to import again later with --incremental flag ? Is that right ?
>
> I thought (at least with --git) the --incremental flag was a no-op for
> the initial import (since we start from scratch, it does a complete
> import).  But Now with the --svn import, on the first import the
> --incremental flag is not a no-op but mandatory.
>
> It's not a big problem, but the behavior of --incremental seems
> different between --git and --svn here.


I don't know how this switch works with git, but I understand it to mean
that this fossil repo should be built with whatever meta information is
needed to allow incremental updating.



-- 
˙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] svn-import branch

[Baruch Burstein]

On Wed, Feb 25, 2015 at 5:09 PM, Martin Gagnon  wrote:

> Baruch plan to use the svn-rev-nn tags to help incremental import logic.
> When using incremental import, it make sense to have those tag because
> when using incremental, it mean you want to keep a svn repository
> synchronized with a fossil repository, the svn-rev-nn tags can be very
> useful in that case, especially when collaborating with people that use
> the svn repo.
>
> But in the case of a definitive migration from a svn repo to fossil
> repo, --incremental option is not likely to happens and the svn-rev are
> not as useful (and can be distracting).


I don't think there needs to be an extra switch (--no-svn-rev) for this. I
think the existing --incremental switch should be used. The default will be
to not have the svn-rev-* tags. They will be added if the --incremental
switch is used. The only effect this switch will have on importing svn
dumps is to turn on this tag, so the extra option is redundant. Also, what
will happen if someone specifies "--incremental --no-svn-rev" together?
This would make no sense since one turns on what the other turns off.
Bottom line - I think the default should be to have them off and
--incremental enables them. I would do it myself but have no time. Maybe
next week.

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

Re: [fossil-dev] svn-import branch

[Baruch Burstein]

On Tue, Feb 24, 2015 at 12:57 AM, Martin Gagnon  wrote:

> Hi,
>
> This is question is mainly for Baruch and Jan, contributer on the
> svn-import branch.
>
> Firstly, Thanks Baruch for the great work, I finally have a reliable way
> to convert my old CVS repository (passing by cvs2svn). I get better
> result than while I was passing by a git repo.
>

Your welcome.


> I've recently start a branch forked from svn-import called
> svn-import_no-svn-rev. I only add a command line option to disable
> the automatic tagging of every checkins with svn-rev-nnn.
>
> While testing the svn-import branch to convert a few repository, I
> found the svn-rev-nnn tags distracting and I think it's a good idea to
> have an option to disable them.
>
> What do you think ?
>

My original intent was to have the svn-rev- tags depend on
the --incremental option. If this option is on, they will be added, since
they will be needed in the future for the next incremental import. I just
never got around to implementing this option at all. My free time seems to
come in bursts, and I don't have much of it right now.



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