[fossil-users] minor grammar suggestions
Hi All, Please see attached patch for your consideration. I found some text for the various settings that could be updated. Thanks! Index: src/db.c == --- src/db.c +++ src/db.c @@ -15,11 +15,11 @@ ** *** ** ** Code for interfacing to the various databases. ** -** There are three separate database files that fossil interacts +** There are three separate database files that Fossil interacts ** with: ** **(1) The "user" database in ~/.fossil ** **(2) The "repository" database @@ -2932,19 +2932,19 @@ ** If enabled, automatically pull the shunning list ** from a server to which the client autosyncs. */ /* ** SETTING: autosyncwidth=16 default=on -** This setting can take either a boolean value or "pullonly" -** If enabled, automatically pull prior to commit -** or update and automatically push after commit or -** tag or branch creation. If the value is "pullonly" +** This setting can take either a boolean value or "pullonly". +** If enabled, automatically pull prior to commit, +** or update and automatically push after commit, +** tag, or branch creation. If the value is "pullonly", ** then only pull operations occur automatically. */ /* ** SETTING: autosync-tries width=16 default=1 -** If autosync is enabled setting this to a value greater +** If autosync is enabled, setting this to a value greater ** than zero will cause autosync to try no more than this ** number of attempts if there is a sync failure. */ /* ** SETTING: binary-glob width=40 versionable block-text @@ -2963,11 +2963,11 @@ #endif #if !(defined(_WIN32)||defined(__CYGWIN__)||defined(__DARWIN__)) /* ** SETTING: case-sensitive boolean default=on ** If TRUE, the files whose names differ only in case -** are considered distinct. If FALSE files whose names +** are considered distinct. If FALSE, files whose names ** differ only in case are the same file. Defaults to ** TRUE for unix and FALSE for Cygwin, Mac and Windows. */ #endif /* @@ -2977,11 +2977,11 @@ ** delete without prompting or allowing undo. ** Example: *.a,*.lib,*.o */ /* ** SETTING: clearsign boolean default=off -** When enabled, fossil will attempt to sign all commits +** When enabled, Fossil will attempt to sign all commits ** with gpg. When disabled, commits will be unsigned. */ /* ** SETTING: crlf-glob width=40 versionable block-text ** The value is a comma or newline-separated list of GLOB patterns for @@ -3201,11 +3201,11 @@ ** password authentication. */ #ifdef FOSSIL_ENABLE_TCL /* ** SETTING: tcl boolean default=off -** If enabled Tcl integration commands will be added to the TH1 +** If enabled, Tcl integration commands will be added to the TH1 ** interpreter, allowing arbitrary Tcl expressions and ** scripts to be evaluated from TH1. Additionally, the Tcl ** interpreter will be able to evaluate arbitrary TH1 ** expressions and scripts. */ ___ 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] Backups of deconstructed fossil repositories
On Sun, Jun 17, 2018, at 20:05, Warren Young wrote: > However, I’ll also give a counterargument to the whole idea: you > probably aren’t saving anything in the end. An intelligent deconstruct > + backup probably saves no net I/O over just re-copying the Fossil repo > DB to the destination unless the destination is *much* slower than the > machine being backed up. > > (rsync was created for the common case where networks are much slower > than the computers they connect. rsync within a single computer is > generally no faster than cp -r, and sometimes slower, unless you take > the mtime optimization mentioned above.) > > The VM/ZFS + snapshots case has a similar argument against it: if you’re > using snapshots to back up a Fossil repo, deconstruction isn’t helpful. > The snapshot/CoW mechanism will only clone the changed disk blocks in > the repo. > > So, what problem are you solving? If it isn’t the slow-networks > problem, I suspect you’ve got an instance of the premature optimization > problem here. If you go ahead and implement it, measure before > committing the change, and if you measure a meaningful difference, > document the conditions to help guide expectations. I want my approximately daily backups to be small. I currently version the fossil SQLite files in borg, and I am considering versioning instead the artefact dumps. I figure these will change less than the SQLite files do and that they also will be smaller because they lack caches. But the backups are already very small. I suppose I could test this. ___ 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] build without zlib doesn't works anymore (using --with-miniz)
On Fri, Jun 29, 2018 at 03:41:58PM -0400, Martin Gagnon wrote: > Hi, > > I use to be able to build fossil for some embedded arm linux without the > need to have zlib available on my cross-compiler toolchain by using > ./configure --with-miniz. > > This doesn't works anymore because it seems that now, shell.c include > zlib.h and links against zlib. > Looks like this checkin is the culprit: http://www.fossil-scm.org/index.html/info/5b558bc76bb9fb5f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] build without zlib doesn't works anymore (using --with-miniz)
Hi, I use to be able to build fossil for some embedded arm linux without the need to have zlib available on my cross-compiler toolchain by using ./configure --with-miniz. This doesn't works anymore because it seems that now, shell.c include zlib.h and links against zlib. Thanks, -- Martin G. ___ 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] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 12:14 PM, Chad Perrin wrote: > On Thu, Jun 28, 2018 at 11:40:01AM -0700, Sam Putman wrote: > > > > As a target, I would suggest the emitted html look as much like this > > as possible: > > > > view-source:https://github.com/jvirkki/libbloom/blob/master/bloom.c > > > > The actual code block begins at line 821. > > > > This style of markup is a de-facto standard and leads to a linking > > style that would greatly aid migration from git if fossil could adhere > > to it. > > I'm not sure how this has any effect on migration from git to fossil, > though. Git export and Fossil import wouldn't touch this code. Are you > talking about some kind of external tools being able to interact with > this code in the browser? If so, the classes involved probably come > from whatever JS library is used for syntax highlighting anyway, rather > than from something like code internal to Fossil (unless syntax > highlighting gets implemented in C as part of Fossil). > > I guess the upshot is that I'm not sure what you mean, and all I've been > able to do so far is guess. > > It's a related but distinct feature, the ability to render links like this one: https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57-L60 Github, Gitlab, and Gogs will all correctly render that link, and various short/relative links of the same form. This is a good convention for making URIs for branches, files, lines, and the like. These URIs get embedded into documentation and tickets, anywhere you might want a hyperlink in your rendered cod. The schema would work as well for fossil as it does for git. Those can't be effectively migrated to fossil, which will display the content hash of the file being rendered as the URI. As for the HTML schema for marking up code, it's also a de-facto standard. Originating with pygments, if I recall correctly and used, with some variation, by all the major syntax highlighters. If the other proposal is just whatever highlights.js emits, I'm sure we'll find that they are somewhere between similar and identical. ___ 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] Patch: Enables integration of syntax highlighting systems
Okay, after all that, I feel like distilling this down to its essence (according to my own opinions, naturally) might be in order. I feel like we basically have three sane options available: 1. Make some very minor changes to the Fossil source, where it generates pretty viewable web pages, to make it much easier to retrofit syntax highlighting via JS libraries for those users who want it. Get someone to write up a currently-effective guide to getting it set up, but make it a sort of unofficial, community guide. Do not officially support syntax highlighting at all. Do not bother screwing around with anything making line numbering play well with JS syntax highlighting unless and until someone presents a patch that fits with this philosophy of not supporting syntax highlighting but enabling it when easy to do so. 2. Pick a single JS syntax highlighting library (highlight.js) to bless. Include a guide in official docs for setting it up in deployment. Specify a supported version range for each Fossil release. Unless line numbering is found to be easy to work in, just write it off and officially declare that line numbering and syntax highlighting do not play well together, but keep that on the radar for figuring out later if possible. Call this "officially tested, but not officially supported". 3. Ship that library with Fossil. There's no need for identifying a supported range: either you use what ships with it or you're on your own, and we don't care any longer. I think taking this approach without resolving the line numbering problem has some issues for purposes of perception of the project, though, so I think one of the following two things should happen here: either call it experimental with firm plans to resolve the line numbering issue before calling it a release feature, or don't do this at all. While using an approach similar to GitHub's for purposes of easing transition from GitHub to self-hosted Fossil would be nice, if it's too much work to do so it shouldn't stand in the way of getting a good solution for Fossil. This feels like one of those "perfect is the enemy of good enough" situations, for a case that is only "perfect" with regard to ensuring people are slightly more inclined to switch from GitHub to self-hosted Fossil. In fact, considering there's probably nobody else providing that kind of fine-grained display characteristics similarity with GitHub, this doesn't feel like a critical issue at all. Most people probably just wouldn't even expect it to be that similar, I'd think. Follow RFCs carefully, provide similarity of implementation to GitHub for convenience if it's not too much trouble, and move on. YMMV. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] persisting uv-files sync confusion
still struggling with this: short version: `fossil clone' seems not to honour the `uv-sync' setting. long version: * server repo created while global `uv-sync' setting was still "off" (if this matters) * server repo is not "open", i.e. no associated checkout (if this matters) * server-side `uv-sync' global setting changed to "on" after creation of server repo (if this matters) * client-side `uv-sync' global setting "on" * from client, `fossil clone -u' does clone uv-files as expected * from client, `fossil clone' does _not_ clone the uv-files despite manpage stating: Setting: "uv-sync" If true, automatically send unversioned files as part of a "fossil clone" or "fossil sync" command. * after opening the clone, `fossil sync' (w/o `-u') behaves as advertised and pull's the uv-files. my fault or fossil's? thank you joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Meta-enhancement
Great! Thanks. On 29 June 2018 at 02:24, Warren Young wrote: > On Jun 28, 2018, at 8:53 PM, David Mason wrote: > > > > Looks nice. What I meant was: what do I have to change to make it work. > > Clone my repository, go into Fossil UI, then navigate to Admin > Tickets. > Copy as much or as little of what you see there into your Admin > Tickets > sections as makes sense for your your purposes. > > Then do the same for Admin > Skins. At minimum here, you’ll want my Bugs > and Wish List button changes. > > You need to copy from a local clone because you won’t be able to get into > my repository’s Admin section via my public Fossil instance, lacking admin > privileges on that instance. > ___ > 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
[fossil-users] Fwd: [fossil-src] activity alert
--- Forwarded message --- From: fossil-...@fossil-scm.org To: veedeeh...@gmail.com Cc: Subject: [fossil-src] activity alert Date: Fri, 29 Jun 2018 13:40:12 +0200 This is an automated email sent by the Fossil repository at https://fossil-scm.org/fossil to report changes. == 2018-06-29 11:40:02 Check-In == Further wording enhancements to the on-line documentation to the "fossil uv" command. (user: drh tags: trunk) https://fossil-scm.org/fossil/info/c4ab8834218197fcc31b sorry for nit-picking, but now it reads: **add FILE ... Add or update unversioned files in the local ** repository so that they match FILEs on disk. ** Use "--as UVFILE" to give the file a different name ** in the repository than what it called on disk. ** Changes are not pushed to other repositories until ** the next sync. "to give the file a different name in the repository than what it called on disk" still seems wrong: a) since there might be multiple files, not only a single one (question: does `--as' only work with a single file or can it be specified multiple times?), b) "than what it called on disk" seems grammatically challenged... how about "to give a file a different name in the repository than what it is called on disk" (or simply "... than on disk")? thank you, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] typos in `fossil help uv'
this has been addressed recently but not completely. there are still some glitches: 12,16c12,16 < repository so that it matches FILE on disk. < Use "--as UVFILE" to give the file a different name < in the repository than what it called on disk. < Changes are not pushed to other repositories until < the next sync. --- repository so that they match FILEs on disk. Use "--as UVFILE" to give a file a different name in the repository than on disk. Changes are not pushed to other repositories until the next sync. On Wed, 27 Jun 2018 14:57:43 +0200, j. van den hoff wrote: patch for `fossil help uv' output: 11,12c11,12