Re: [fossil-users] blame/annotate webview not working for me.
On Sun, Dec 17, 2017 at 8:40 PM bch wrote: > I'm using recent fossil: > kamloops$ fossil version > This is fossil version 2.5 [5419e7fcec] 2017-12-15 18:27:08 UTC > > > trying to view annotate/blame for a file, and on Firefox (Build > identifier: Mozilla/5.0 (X11; NetBSD amd64; rv:57.0) Gecko/20100101 > Firefox/57.0) I get this: > > > The connection was reset > > The connection to the server was reset while the page was loading. > > > Has anybody else seen something like this? > I bisected and during the course of checkouts, must have ‘jiggled’ a src file to trigger the right rebuild so the “problem” binary (now rebuilt) works fine. -bch > Cheers, > > -bch > ___ 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] tangent vs. wyoung on recent commti
On Sun, Dec 17, 2017 at 9:11 PM, wrote: > > Date: Sun, 17 Dec 2017 18:13:17 + > From: Mark Janssen > Subject: Re: [fossil-users] tangent vs. wyoung on recent commti > > Then what is the point of recvfrom? It will then just reduce to the repo > where the artifact was created. This might be useful, but it is not what > recvfrom means. > All I'm suggesting is that the information already being put in the "rcvfrom" table (that DRH mentioned) also be saved as tags to the commits they refer to. Therefore, the tags will have the same meaning as the entries in the existing "rcvfrom" table. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] blame/annotate webview not working for me.
I'm using recent fossil: kamloops$ fossil version This is fossil version 2.5 [5419e7fcec] 2017-12-15 18:27:08 UTC trying to view annotate/blame for a file, and on Firefox (Build identifier: Mozilla/5.0 (X11; NetBSD amd64; rv:57.0) Gecko/20100101 Firefox/57.0) I get this: The connection was reset The connection to the server was reset while the page was loading. Has anybody else seen something like this? Cheers, -bch ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Please suggest built-in skin fixes and improvements
You can now see the canonical Fossil self-hosting repository using any of the built-in skins by visiting links from this page: https://www.fossil-scm.org/skins/ I have fixed a few of the more egregious problems in these built-ins that have resulted from the recent Modern View timeline and other enhancements. But more refinement is necessary. Please suggest additional fixes. I mean by this, please suggest the actually CSS changes needed to fix the problem - don't just point out that it doesn't look right and expect me to figure out the problem and a fix. Thanks for your help! -- D. Richard Hipp d...@sqlite.org ___ 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] tangent vs. wyoung on recent commti
On Fri, 15 Dec 2017 13:52:55 -0500, D. Richard Hipp wrote: >On 12/15/17, Andy Bradford wrote: >> Thus said Warren Young on Thu, 14 Dec 2017 12:13:18 -0700: >> >>> Fossil arguably has a bug here, where if you check a change in as >>> local user name ``tangent'', as I do here, then *later* do a ``fossil >>> sync'' to a URL with a user name, some bit of the local on-disk state >>> remembers that you originally cloned the repo as tangent and makes >>> your changes under that name. >> >> I disagree that this is a bug. I consider it useful flexibility. >> >>> I classify this as a bug because it could be used for an impersonation >>> attack. >> >> Fossil records which user synchronized the content in the recvfrom table >> so the owner of the remote repository knows who did it if he cares. >> >> As stated in the past, Fossil is meant for a tighter group of >> developers---perhaps this perception has changed--- one in which >> impersonation is unlikely. >> > >I was very aware of all of these factors when I designed Fossil, 10 >years ago. Impersonation was a concern. But in a DVCS, there really >is no way around it. > >Defenses include: > >(1) The rcvfrom table that shows clearly where all artifacts >originated, thus allowing the originator of a deception to be tracked >down and dealt with administratively. > >(2) Check-ins can be signed using GPG or PGP. (I do this on TH3, fwiw.) >-- I believe deception and impersonation are important. I would recommend the study of block chain or blockchain technologies, such as Bitcoin. These technologies use signed hashes. I have found they have a significant perspective on when an event occurs, in what order events occur and who is the originator of the event. An interesting, and annoying, deception I found a few years ago was where someone added a copyright comment in several pre-existing open source program sources, as if they were the author. Another example is where the original author is over written, or not mentioned or barely mentioned. I was working at a bank in 2001, where a programmer got an award for installing a major fix very quickly. The designer had a big smile on his face, because the programmer simply copied the exact code from the designer and implemented it. The designer was never mentioned. Most of us have similar stories. ___ 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] tangent vs. wyoung on recent commti
Then what is the point of recvfrom? It will then just reduce to the repo where the artifact was created. This might be useful, but it is not what recvfrom means. Op zo 17 dec. 2017 18:11 schreef Ron W : > On Sun, Dec 17, 2017 at 7:00 AM, < > fossil-users-requ...@lists.fossil-scm.org> wrote: >> >> Date: Sun, 17 Dec 2017 09:56:57 + >> From: Mark Janssen >> Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28 >> Message-ID: >> > o5bgtr...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Unless I am misunderstanding what you mean by permanent record, I don't >> think this is possible in a DVCS. In a DVCS the remote can be different >> and >> even change between pull/syncs >> > > I was referring to the difference between "artifacts" and entries in a > table in the database. > > Fossil only sync's artifacts between repositories. Anything in the db that > isn't an artifact is local metadata. > > Besides tags added when a commit is made, Fossil allows additional tags to > be created. It does this by creating "control artifacts", therefore making > these additional tags sync-able between repos. > > By adding "rcvfrom" tags to commits received from the other repos, any > given commit would then be trace-able to its originating repo - even if any > of the intermediate repos is no longer available. > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ 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] tangent vs. wyoung on recent commti
On Sun, Dec 17, 2017 at 7:00 AM, wrote: > > Date: Sun, 17 Dec 2017 09:56:57 + > From: Mark Janssen > Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28 > Message-ID: > bgtr...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Unless I am misunderstanding what you mean by permanent record, I don't > think this is possible in a DVCS. In a DVCS the remote can be different and > even change between pull/syncs > I was referring to the difference between "artifacts" and entries in a table in the database. Fossil only sync's artifacts between repositories. Anything in the db that isn't an artifact is local metadata. Besides tags added when a commit is made, Fossil allows additional tags to be created. It does this by creating "control artifacts", therefore making these additional tags sync-able between repos. By adding "rcvfrom" tags to commits received from the other repos, any given commit would then be trace-able to its originating repo - even if any of the intermediate repos is no longer available. ___ 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] Tag problems
The following command fails: $ fossil tag add -n --user-override username tagname checkin But this one works as expected: $ fossil tag add --dryrun --user-override username tagname checkin That's because -n is the short form for both --limit and --dryrun: http://fossil-scm.org/index.html/artifact?ln=440&name=24c77636171affc2 http://fossil-scm.org/index.html/artifact?ln=457&name=24c77636171affc2 I think the short form for --limit should be changed, because -n|--dryrun is also used by a few other commands. While at it, I noticed that --dryrun is sometimes spelled --dry-run, maybe this could be unified? --Florian ___ 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] Tag problems
On 16 December 2017 at 20:33, Andy Bradford wrote: > Thus said David Mason on Sat, 16 Dec 2017 15:36:51 -0500: > > > I tried to add a tag to my fossil. After looking at the documentation > > which said: > > The ``fossil tag'' command is for very low-level tag operations. You > probably don't want to use it until you understand what it's doing. > > If you do actually want to add tags to commits from the command-line you > might want to look at ``fossil amend'' instead---it more closely mirrors > what is available in the UI: > Fair enough. It would be helpful if the documentation said that. The other options don't seem to work as advertised, either. Perhaps they only work if the magic values are supplied, but again, it would be helpful if the documentation said that. ../Dave ___ 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] fossil-users Digest, Vol 119, Issue 28
Unless I am misunderstanding what you mean by permanent record, I don't think this is possible in a DVCS. In a DVCS the remote can be different and even change between pull/syncs Op za 16 dec. 2017 21:42 schreef Ron W : > On Sat, Dec 16, 2017 at 7:00 AM, < > fossil-users-requ...@lists.fossil-scm.org> wrote: > >> Date: Fri, 15 Dec 2017 13:52:55 -0500 >> From: Richard Hipp >> Subject: Re: [fossil-users] tangent vs. wyoung on recent commti >> >> On 12/15/17, Andy Bradford wrote: >> > As stated in the past, Fossil is meant for a tighter group of >> > developers---perhaps this perception has changed---one in which >> > impersonation is unlikely. >> > >> >> I was very aware of all of these factors when I designed Fossil, 10 >> years ago. Impersonation was a concern. But in a DVCS, there really >> is no way around it. >> >> Defenses include: >> >> (1) The rcvfrom table that shows clearly where all artifacts >> originated, thus allowing the originator of a deception to be tracked >> down and dealt with administratively. >> > > Maybe there should be a way to store this rcvfrom table in artifacts so > the data is part of the permanent Fossil record. > > Maybe as control artifacts to auto-tag each each commit received via > sync/pull/push? > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
