Re: [fossil-users] SlackBuilds.org GitHub repository and DMCA Takedown notice
On 6/17/18, Andy Goth wrote: > > Am I correct in my understanding that all a Fossil repository need do is > issue shun artifacts for each file in the takedown notice? If the files > had multiple versions (they didn't in this case), shun each version of > them too, right? > I think that is correct, yes. -- 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
[fossil-users] SlackBuilds.org GitHub repository and DMCA Takedown notice
A few days ago, SBo and over 200 other repositories in GitHub were hit with a DMCA Takedown notice due to having a couple header files from Steinberg Media Technologies. There's a lot to say about that, particularly if you're into computer music synthesis, but I don't think this mailing list is the appropriate forum to discuss Steinberg's action. Instead I want to discuss the technical means by which any of the affected projects would comply with the takedown, had they been using Fossil. Quote from the SBo blog post: "The admins have discussed this matter last night and we came to a solution of fixing this issue permanently by removing the related commit and all the history for this script in master and 14.2 branch. This is not a trivial action as the commits involved were 11867 since 2017-02-04. Ponce did the initial testing and David did the final touch, including pushing an unexpected public update including with the mass re-base on master and 14.2 branch (Thanks David)." The post goes on to include a sequence of commands to be followed by everyone downstream to surgically fix their local clone of the SBo repository. "[A] simpler way is to re-clone our repository using git clone." Am I correct in my understanding that all a Fossil repository need do is issue shun artifacts for each file in the takedown notice? If the files had multiple versions (they didn't in this case), shun each version of them too, right? This would result in the file vanishing from every repository clone upon the next sync, though its name and checksum would remain in manifests. Any code #include'ing the header files (in this case) would fail to compile, on account of the missing file, so it would no longer be possible to recompile historical check-ins, not without creating a compatible replacement for the shunned files. Here's the original blog post I found: https://slackblogs.blogspot.com/2018/06/sbo-dmca-takedown.html For your curiosity, here's Google's cache of one of the affected files, but I'm sure Google will take it down too, so look quick. Right now, the important part is the comment "© 2006, Steinberg Media Technologies, All Rights Reserved". https://webcache.googleusercontent.com/search?q=cache:X4F7NEfgUlkJ:https://github.com/aardvarkk/soundfind/blob/master/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h+=1=en=clnk=us=firefox-b-1 -- Andy Goth | ___ 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] Using bundles for pull requests
A simpler alternative to having a dedicated pull-request feature in fossil is to just have a second "free-for-all" repository where commit capability is granted to pretty much any passerby willing to fill out a CAPTCHA and register an account. Said passerby can then just use the ticket system (or a mailing list, or the built-in forum that drh seems to have started working on) to notify the main repository developers that a pull-request exists on some particular branch in the free-for-all repository. A developer on the main repository then uses `fossil bundle` (or some improved version thereof) to import the changes on that specific branch into the main repository, possibly altering them in the process (i.e. by importing the bundle as a private branch, then "rebasing" or compressing the changes onto a different public branch). The comments Florian and I made about `bundle import` security still apply, though. There needs to be some way for a developer to ensure the bundle they're importing will not "spray" checkins and control artifacts all over the repository. By the way, the current `bundle ls` implementation just trusts the `notes` column of the `bblob` table; it doesn't actually check the blob contents. Best, Eduard ___ 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 6/17/18, Thomas Levine <_...@thomaslevine.com> wrote: > As content is added to a fossil repository, files in the corresponding > deconstructed repository never change; they are only added. Most backup > software will track changes to the deconstructed repository with great > efficiency. > > I should thus take my backups of the deconstructed repositories, yes? Fossil itself tracks changes with great efficiency. The best backup of a fossil repository is a clone. The self-hosting Fossil repo at https://fossil-scm.org/ is backed up by two clones, one at https://www2.fossil-scm.org/ and the other at https://www3.fossil-scm.org/site.cgi. Each of these clones is in a separate data center in a different part of the world. The second clone uses a different ISP (DigitalOcean instead of Linode). Both clones sync to the master hourly via a cron job. -- 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] A fossil library
On Sun, Jun 17, 2018 at 6:39 AM, David Mason wrote: > Just had a quick thought that might make the conversion to library much > easier. > > If you have a relatively small API interface, each of the API functions > could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h and then the > fatal error routines could longjmp back. This would give you API safety, at > very limited code intervention. And if a flag got set by the API functions, > then the fatal routines could check, so that fossil the program would need > no changes as only the API functions would change the default fail-hard > behaviour. > > But perhaps the API would be too big to make this a win. > > Just a thought. > > ../Dave > > > This is the kind of approach I glossed over as a "goto cleanup", so we're on the same track here. I haven't had a chance to go over some of the core C files in libfossil yet, curious to what degree it follows this pattern already. Stephan has indicated that allocation is necessarily somewhat more fine-grained than this, and elsewhere in the documentation, exceptions are mentioned... -Sam ___ 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] A fossil library
On Sun, Jun 17, 2018 at 4:50 AM, Stephan Beal wrote: > On Sat, Jun 16, 2018 at 11:44 PM Sam Putman wrote: > >> >> An incremental refactoring of this into something more modular would >> be a boon to maintenance and testing. Seems like a sleeping dog we can >> let lie for now. >> > > That's actually the easy part. The real effort comes in with error > checking and handling, especially in cases where an error may (in a > library) propagated from 3+ levels deep. The app will just exit() at that > point, so no thought has gone (nor needed to go) into error handling or > propagation (because there is no propagation - all errors are "immediate"). > Not only does the propagation at the error-triggering point need to be > decided upon, but how it will propagate arbitrarily far up the call stack. > In the end, libfossil went with a hybrid approach of returning non-0 (from > a well-defined enum of result codes) and the context object holds an Error > object which may (or may not, depending on context) hold more details about > the error. > > About those objects... What your docs call fossil(1) is written in plain C. Or rather C, Tcl, SQL and TH1, if you prefer. In any case, not C++. We have fairly strict requirements for the languages we include in our own runtime, because we intend to parse both the syntax and the static semantics of the languages we use. That makes C++ a non starter, as I would imagine it is for including a libfossil as the core of fossil(1). Even for my own needs, the C89-99 family hits the sweet spot; I'm tolerant of ANSIsms in old code but try not to emit them personally. Given that, I'll skip ahead a bit: > > >> >> I concur with Warren that the effort of a libfossil is best justified if >> it becomes the core of fossil proper. >> > > Absolutely 100%, but it's essentially impossible to back-port it into > fossil proper without some massive upheaval. Since fossil lies at the heart > of the sqlite project, there's not (in my somewhat conservatively cautious > view) much room for such severe upheaval. A 3rd-party implementation is > interesting in and of itself, but it would also potentially be a point of > contention, as you say... > I'm still pretty convinced the work on libfossil won't go to waste. The excellent documentation alone has advanced my understanding considerably. What might make sense is a sort of 'parallel construction'. Nice thing about a revision control system, it's got all the revisions. So to write a clean C libfossil, we can start with the first commit and follow the breadcrumbs. > > Tasks like isolating those core intricate algorithms into well-documented >> modules, where >> errors and edge cases are handled where they occur, this can really pay >> off. >> > > That's all in libfossil. > > >> Merging and patch theory are >> areas where real conceptual leaps are still happening. >> > > libfossil has all of fossil's diff algorithms but i don't think i ever > ported the full merge support (it can apply deltas but i don't recall > porting the type of merging decisions which are made during, e.g., a > checkout). Speaking of merging: that's often an interactive process, and > interactivity is difficult to define in a UI-ignorant library. > > This is a legitimately hard problem. Pijul's approach of having a conflict object instead of spraying the merge conflict all over the source file has potential. I don't think it's strongly tied to the patch-centric model, it's a (relatively) simple matter of representing possible outcomes as distinct states. There might be some potentially exponential bad behavior, we are talking about permutations after all. I'm way ahead of myself there; this is just to say that we can most likely do better than pushing a diff into the source code, while still providing a library API. > The one area of fossil I've done enough reading into to feel comfortable >> in my understanding is the >> file format itself. There's an edge to the documentation and I'm kinda >> peering over that edge slightly. >> > > The "artifact format" documentation is really Fossil's heart. All of the > other parts are implementation details for supporting that. Nonetheless, > any port will certainly want to take advantage of as many of those details > as possible (much of fossil's "heavy lifting" is done with sqlite, and > reimplementing many of those pieces without sqlite would be a massive > undertaking). > SQLite is a core library for bridgetools. I took to heart the "SQLite as alternative to fopen()" slogan, one of the best architectural decisions I've made. That's why we're using fossil as our DVCS, no matter what happens with this libfossil proposal. We are / will be using SQLite for dependency management, bundling, and application file formats already, and even if we have to shell out to fossil(1) we're ahead of the game using a compatible format for our repos. But those intricate algorithms for deduplication, hash chaining, and merging, those
Re: [fossil-users] Perception of Fossil
On Sun, 17 Jun 2018 20:49:25 +0200 Karel Gardas wrote: > On Fri, 15 Jun 2018 13:35:13 -0400 > Richard Hipp wrote: > > > An alternative design sketch: > > > > (1) Anonymous clones repo CoolApp > > > > (2) Anonymous makes changes to CoolApp and checks those changes into a > > branch named "anon-patch" on her private clone. Repeat this step as > > necessary to get anon-patch working. > > > > (3) Anonymous runs the command "fossil pullrequest anon-patch" > > > > (4) The pullrequest command creates a "bundle" out of the "anon-patch" > > branch and then transmits that bundle back to the server from which > > the clone originated. > > > > (5) The server accepts the bundle and parks it in a separate holding > > table, but does not merge it or otherwise make it available to average > > passers by. The server then sends email notifications to developers > > with appropriate privileges to let them know that a pull request has > > arrived. > > Please no, this would be real security nightmare. Anyone can attack any > fossil public repo then by simple DoS. Do not ever allow anonymous to play > with your pristine repository! If anon needs to "push" something, then he/she > needs to make his/her repo public and *you* can investigate the patch of > her/him first. > > Thanks, > Karel At first it seems you underestimate the ability of fossil to withstand high load. But then, there are many ways to overload web server without pushing bundles. My experience is that fossil is pretty hard to be overloaded, even on very lightweight servers. At second, it can be made a little bit different: The permission to push bundles to be assigned to the self-registered users and to be limited by number of requests per day and/or the maximal size of the bundle pushed. This way the abusers can be banned effectively. -- http://fresh.flatassembler.net http://asm32.info John Found ___ 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 10:08 PM Warren Young wrote: > On Jun 17, 2018, at 2:05 PM, Warren Young wrote: > > > > If you’re willing to gamble that if the first test returns true that the > second will also returns true, it buys you a big increase in speed. The > gamble is worth taking as long as the files’ modification timestamps are > trustworthy. > > I just remembered something: “fossil up” purposely does not modify the > mtimes of the files it writes to match the mtime of the file in the > repository because it can cause difficult-to-diagnose build system errors. > Writing changed files out with the current wall time as the mtime is more > likely to cause correct builds. > To that i'm going to add that fossil doesn't actually store any file timestamps! It only records the time of a commit. When fossil is asked "what's the timestamp for file X?", the answer is really the timestamp of the last commit in which that file was modified. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ 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 Jun 17, 2018, at 2:05 PM, Warren Young wrote: > > If you’re willing to gamble that if the first test returns true that the > second will also returns true, it buys you a big increase in speed. The > gamble is worth taking as long as the files’ modification timestamps are > trustworthy. I just remembered something: “fossil up” purposely does not modify the mtimes of the files it writes to match the mtime of the file in the repository because it can cause difficult-to-diagnose build system errors. Writing changed files out with the current wall time as the mtime is more likely to cause correct builds. I wonder if the fossil deconstruct mechanism also does the same thing? If so, then you can’t take the rsync mtime optimization without changing that behavior. ___ 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 Jun 17, 2018, at 12:16 PM, Thomas Levine <_...@thomaslevine.com> wrote: > > One inconvenience I noted is that the deconstruct command always writes > artefacts to the filesystem, even if a file of the appropriate name and > size and contents already exists. You might want to split that observation into two, as rsync does: - name, size, and modification date match - contents also match If you’re willing to gamble that if the first test returns true that the second will also returns true, it buys you a big increase in speed. The gamble is worth taking as long as the files’ modification timestamps are trustworthy. When the timestamps aren’t trustworthy, you do the first test, then if that returns true, also do the second as extra assurance. > Would the developers welcome a flag > to blob_write_to_file in src/blob.c to skip the writing of a new > artefact file if the file already exists? In addition to your backup case, it might also benefit snapshotting mechanisms found in many virtual machine systems and in some of the more advanced filesystems. (ZFS, btrfs, APFS…) 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. ___ 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] Perception of Fossil
On Fri, 15 Jun 2018 13:35:13 -0400 Richard Hipp wrote: > An alternative design sketch: > > (1) Anonymous clones repo CoolApp > > (2) Anonymous makes changes to CoolApp and checks those changes into a > branch named "anon-patch" on her private clone. Repeat this step as > necessary to get anon-patch working. > > (3) Anonymous runs the command "fossil pullrequest anon-patch" > > (4) The pullrequest command creates a "bundle" out of the "anon-patch" > branch and then transmits that bundle back to the server from which > the clone originated. > > (5) The server accepts the bundle and parks it in a separate holding > table, but does not merge it or otherwise make it available to average > passers by. The server then sends email notifications to developers > with appropriate privileges to let them know that a pull request has > arrived. Please no, this would be real security nightmare. Anyone can attack any fossil public repo then by simple DoS. Do not ever allow anonymous to play with your pristine repository! If anon needs to "push" something, then he/she needs to make his/her repo public and *you* can investigate the patch of her/him first. Thanks, Karel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Backups of deconstructed fossil repositories
As content is added to a fossil repository, files in the corresponding deconstructed repository never change; they are only added. Most backup software will track changes to the deconstructed repository with great efficiency. I should thus take my backups of the deconstructed repositories, yes? That is, should I back up the SQLite database format of the fossil repository or the deconstructed directory format of the repository? One inconvenience I noted is that the deconstruct command always writes artefacts to the filesystem, even if a file of the appropriate name and size and contents already exists. Would the developers welcome a flag to blob_write_to_file in src/blob.c to skip the writing of a new artefact file if the file already exists? That is, rebuild_step in src/rebuild.c would check for the existance of the file corresponding the artefact's hash, and if such a file exists already (even if its content is wrong), rebuild_step would skip writing this artefact. ___ 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] Perception of Fossil
On Sun, 17 Jun 2018 04:06:50 + Chad Perrin wrote: > On Sat, Jun 16, 2018 at 05:05:48PM +0200, Eduardo Morras wrote: > > > > I partially disagree. If you allow anonymous people to pull / > > commit / merge data to your 'central repository', you can get > > easily spammed. If I pull-request 100 images of 10MB your system > > will go down. Multiply it by several 'funny guys' on more than one > > repository and fossil credibility / reputation will be -1. > > > > People that could pull anything to any repository must be trust > > people. (Don't know if it's correct phrase) > > I think that's a matter for configuration, just like whether to allow > people to self-register through the web UI and what initial > permissions a registered user should have. It is not, in my > estimation, a matter of whether or not this is a desirable feature > *at all*. I'm not against the feature, I was pointing security defects that Dr. Hipps didn't describe in his feature description and could end being a bad implementation. Discovering them after or by third persons could destroy fossil credibility. > This could, in fact, be a very important feature for some team > workflows where there may be some devs who are allowed to do this, > and others who are allowed to commit/push directly (and given the > ability to handle a contributed branch like this, to merge or > otherwise accept). Yes, the concept of core developers with commit bit and developers that submit patches to pr or bugtrack system for commit aproval is common in opensource projects. I'm a freebsd / openbsd fan and it's how those projects work. As fossil has the bug tracking inside it's logical to add this feature. > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] --- --- Eduardo Morras ___ 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] Change textarea for textnotes to placeholder text
On Sun, Jun 17, 2018, 15:26 Zack Scholl wrote: > > > [1]: https://www.w3schools.com/tags/att_textarea_placeholder.asp > > [2]: > https://www.fossil-scm.org/index.html/artifact?udc=1=on=5d4a12252f765b5a > Just fyi: the ln= param accepts both a single line number or range of lines (e.g. ln=20-30): https://www.fossil-scm.org/index.html/artifact?udc=1=544=5d4a12252f765b5a - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. ___ 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] Change textarea for textnotes to placeholder text
On Sun, Jun 17, 2018 at 06:26:06AM -0700, Zack Scholl wrote: > > I made this change in a forked copy of fossil (simply change are line 544 > of event.src to add the placeholder [2] and delete "Insert new content > here..." from line 474) ... > > [2]: > https://www.fossil-scm.org/index.html/artifact?udc=1=on=5d4a12252f765b5a Hi Zack, Here's a Useful trick when passing link to source on fossil repo, you can specify lines to highlight. (in your case, for 2 separate lines, you can edit the url and change "ln=on" to "ln=474+544" like this [1] See all the options for the /artifact page here: [2] [1]: https://www.fossil-scm.org/index.html/artifact?udc=1=474+544=5d4a12252f765b5a [2]: https://www.fossil-scm.org/index.html/help?cmd=/artifact Regards, -- 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] A fossil library
Just had a quick thought that might make the conversion to library much easier. If you have a relatively small API interface, each of the API functions could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h and then the fatal error routines could longjmp back. This would give you API safety, at very limited code intervention. And if a flag got set by the API functions, then the fatal routines could check, so that fossil the program would need no changes as only the API functions would change the default fail-hard behaviour. But perhaps the API would be too big to make this a win. Just a thought. ../Dave On 17 June 2018 at 07:50, Stephan Beal wrote: > On Sat, Jun 16, 2018 at 11:44 PM Sam Putman wrote: > >> I'll be reading through the codebase and documentation, some initial >> thoughts: >> > > No pressure, but: i would _love_ to see someone pick up the torch and run > with it. > > A bit of background: in Sept. 2011 i had the great pleasure of meeting > Richard in Munich (at which point i'd been active on the mailing list since > early 2008). He asked me what Fossil needed, to which i immediately > responded "a library". We quickly came to the conclusion that the effort > would be "herculean" (i believe was his (apt) description of it (or maybe > that adjective got applied on the mailing list later on)), so i responded > with my second choice: a JSON interface. (HTTP/JSON interfaces are, in > essence, shared libraries with call-time linking. Many of Fossil's features > simply aren't realistic for a JSON interface, but most are.) Richard > promptly agreed, and i spent the next few months building the JSON API > (using a then-recent JSON wiki project of mine as the "structural basis"). > > Anyway... > > >> >> >>> Several aspects of fossil make it very tedious (but not difficult, per >>> se) to port to a library: >>> >>> 1) it uses a great deal of global state. That's simple enough to factor >>> into a Context object, but... >>> >>> >> An incremental refactoring of this into something more modular would >> be a boon to maintenance and testing. Seems like a sleeping dog we can >> let lie for now. >> > > That's actually the easy part. The real effort comes in with error > checking and handling, especially in cases where an error may (in a > library) propagated from 3+ levels deep. The app will just exit() at that > point, so no thought has gone (nor needed to go) into error handling or > propagation (because there is no propagation - all errors are "immediate"). > Not only does the propagation at the error-triggering point need to be > decided upon, but how it will propagate arbitrarily far up the call stack. > In the end, libfossil went with a hybrid approach of returning non-0 (from > a well-defined enum of result codes) and the context object holds an Error > object which may (or may not, depending on context) hold more details about > the error. > > > >> 2) it relies on a fail-fast-and-fail-loud allocator. Any allocation error >>> will immediately (intentionally) crash the app. While that saves literally >>> half (sometimes more) of code/error checking any place where memory is >>> allocated (that's a lot of places), that pattern is unusable for libraries. >>> Granted, allocation errors are rare, but every single C call which >>> allocates has to check for failure or risk Undefined Behaviour. To simplify >>> the vast majority of the implementation, Fossil does this checking in a >>> single place and abort()s the app if an allocation fails. >>> >>> >> Ok, this doesn't sound /ideal/ granted, but maybe not so bad either. >> > > Because allocations fail so rarely (at least ostensibly), it's "not that > big of a deal", but the library-level implementation code "needs" (in my > somewhat-purist point of view) to check for allocation errors nonetheless. > App-level code is free to use a fail-fast allocator, and libfossil's > app-level code did, in fact, use one because it speeds up writing the > app-level code so much. Fossil does _lots_ of allocation, and does, in > fact, sometimes run out of memory. i've never seen it happen on my > machines, but i've seen several reports from users who try to store > multi-GB files in fossil and then wonder why it fails on their Raspberry > Pi. Fossil needs scads of memory. Certain parts of that "could" > hypothetically be optimized to only alloc what they need (e.g. the diff > generator could arguably stream its output), but (1) that would greatly > complicate those parts and (2) very possibly wouldn't result in a leaner > app. e.g. constructing version X of a file from its parent version and the > diff of the versions requires allocating memory for X, X's parent, and the > diff (it knows all of those sizes in advance). In the average case that's > just a bit over 2X memory for each such operation, and fossil regularly has > to perform such an operation during many different types of activities. > > > >> I would likely prefer as much allocation as possible during
[fossil-users] Change textarea for textnotes to placeholder text
Hi, I had a very small and mildly useful change in mind: to move the "Insert new content here..." text for the technical note textarea to a textarea placeholder [1]. Basically I like to make tech notes on my phone and every time I do I have to highlight and delete the " Insert new content here... ". I made this change in a forked copy of fossil (simply change are line 544 of event.src to add the placeholder [2] and delete "Insert new content here..." from line 474) and I thought I'd pass this along. I'd be happy to contribute to the code (though I don't know how) and equally happy if you choose to ignore this! - Zack [1]: https://www.w3schools.com/tags/att_textarea_placeholder.asp [2]: https://www.fossil-scm.org/index.html/artifact?udc=1=on=5d4a12252f765b5a ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Using fossil with Golang (go get)
I noticed that there was some interest that Go started supporting fossil [1]. I was really happy that this change came about too, but I hadn't tried playing with it until now. I initially had a lot of trouble getting `go get` to work with my fossil, and eventually found the very simple solution which I'll share in case anyone else also gets stuck like me. All you need to do is update your "Header" skin (Admin -> Skins) to include a special meta tag that `go get` will fetch to interpret your fossil as a Go library/program. For example, if you have a fossil hosted at https://yourdomain.com/hello-world then you need to add the meta tag in between the tags: https://yourdomain.com/hello-world;> There's an explanation in the Golang docs [2], but basically the first part "yourdomain.com/hello-world" is the package to be fetched, "fossil" tells Go which VCS to use, and "https://yourdomain.com/hello-world; is the root. Now you can just do `go get yourdomain.com/hello-world`. [1]: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27038.html [2]: https://golang.org/cmd/go/#hdr-Remote_import_paths ___ 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] A fossil library
On Sat, Jun 16, 2018 at 11:44 PM Sam Putman wrote: > I'll be reading through the codebase and documentation, some initial > thoughts: > No pressure, but: i would _love_ to see someone pick up the torch and run with it. A bit of background: in Sept. 2011 i had the great pleasure of meeting Richard in Munich (at which point i'd been active on the mailing list since early 2008). He asked me what Fossil needed, to which i immediately responded "a library". We quickly came to the conclusion that the effort would be "herculean" (i believe was his (apt) description of it (or maybe that adjective got applied on the mailing list later on)), so i responded with my second choice: a JSON interface. (HTTP/JSON interfaces are, in essence, shared libraries with call-time linking. Many of Fossil's features simply aren't realistic for a JSON interface, but most are.) Richard promptly agreed, and i spent the next few months building the JSON API (using a then-recent JSON wiki project of mine as the "structural basis"). Anyway... > > >> Several aspects of fossil make it very tedious (but not difficult, per >> se) to port to a library: >> >> 1) it uses a great deal of global state. That's simple enough to factor >> into a Context object, but... >> >> > An incremental refactoring of this into something more modular would > be a boon to maintenance and testing. Seems like a sleeping dog we can > let lie for now. > That's actually the easy part. The real effort comes in with error checking and handling, especially in cases where an error may (in a library) propagated from 3+ levels deep. The app will just exit() at that point, so no thought has gone (nor needed to go) into error handling or propagation (because there is no propagation - all errors are "immediate"). Not only does the propagation at the error-triggering point need to be decided upon, but how it will propagate arbitrarily far up the call stack. In the end, libfossil went with a hybrid approach of returning non-0 (from a well-defined enum of result codes) and the context object holds an Error object which may (or may not, depending on context) hold more details about the error. > 2) it relies on a fail-fast-and-fail-loud allocator. Any allocation error >> will immediately (intentionally) crash the app. While that saves literally >> half (sometimes more) of code/error checking any place where memory is >> allocated (that's a lot of places), that pattern is unusable for libraries. >> Granted, allocation errors are rare, but every single C call which >> allocates has to check for failure or risk Undefined Behaviour. To simplify >> the vast majority of the implementation, Fossil does this checking in a >> single place and abort()s the app if an allocation fails. >> >> > Ok, this doesn't sound /ideal/ granted, but maybe not so bad either. > Because allocations fail so rarely (at least ostensibly), it's "not that big of a deal", but the library-level implementation code "needs" (in my somewhat-purist point of view) to check for allocation errors nonetheless. App-level code is free to use a fail-fast allocator, and libfossil's app-level code did, in fact, use one because it speeds up writing the app-level code so much. Fossil does _lots_ of allocation, and does, in fact, sometimes run out of memory. i've never seen it happen on my machines, but i've seen several reports from users who try to store multi-GB files in fossil and then wonder why it fails on their Raspberry Pi. Fossil needs scads of memory. Certain parts of that "could" hypothetically be optimized to only alloc what they need (e.g. the diff generator could arguably stream its output), but (1) that would greatly complicate those parts and (2) very possibly wouldn't result in a leaner app. e.g. constructing version X of a file from its parent version and the diff of the versions requires allocating memory for X, X's parent, and the diff (it knows all of those sizes in advance). In the average case that's just a bit over 2X memory for each such operation, and fossil regularly has to perform such an operation during many different types of activities. > I would likely prefer as much allocation as possible during load. An > allocation error during this stage > is a show-stopper. > Because fossil can be used in several discrete ways (e.g. within a checkout, with (only) a repo, and with neither checkout nor repo (for a limited subset of operations)), it's impossible to supply a single init operation. An app needs to tell fossil to init into some specific mode of operation, and the API "should" allow the user to toss that away and re-init with a different mode (but that's kind of a free feature when you create the API as library-centric). > 3) Fossil effectively uses exit() to handle just about any type of >> non-allocation error. i.e. there's little library-friendly error handling >> in fossil. >> >> > I guess this bullet depends on how much error handling is possible at > those points, and how
Re: [fossil-users] Using bundles for pull requests
Richard Hipp: > (5) The server accepts the bundle and parks it in a separate holding > table, but does not merge it or otherwise make it available to average > passers by. The server then sends email notifications to developers > with appropriate privileges to let them know that a pull request has > arrived. > (6) Developers who receive notification of the pull request can run a > command that pulls down the bundle and applies it as a private branch > on their own personal clones of the repo. Developers can then either > approve of the pull request by publishing it (marking it non-private) > and pushing it back to the server. Or they can reject the pull request > which erases it from their clone. They might also cause the pull > request to be erased from the holding table on the server. From my experience with GitHub pull requests, it seems that they are visible to the public and open for review and comments even before they are reviewed and accepted by the upstream project, and anybody interested can take the submitted code to their own clone. It has a less "open" character if core developers need to become active to make pull requests visible to the public, more so if they can delete submissions without anybody from outside of their team ever noticing. If bundles were reworked to be "sets of patches", they could me made visible to the public more easily, before reaching the main repository store. And there would be the already mentioned greater flexibility with meta-data (allowing the receiver to decide about the merge base, the check-in comments, as well as the branch name and other tags). --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] [sqlite] Mailing list shutting down...
> Le 14 juin 2018 à 22:47, Warren Young a écrit : > >> having to have browser tabs open for dozens of web forums > > I bookmark all of the sites I need to go to regularly and place them in a > folder in my browser’s bookmark bar so that I can open them all at once with > a Cmd- or Ctrl-Click on the folder. As I read each forum, I close that tab. > > I actually keep two such folders, “Daily” and “Weekly,” suggesting my > visiting frequency, which is set by how often I expect interesting content to > appear. I have a similar routine, but does so all within my email application, which I find much more effective for the task. I'm happy you found what works for you. It just doesn't match my preferences, but that is OK and increases cultural richness. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] [sqlite] Mailing list shutting down...
> Le 14 juin 2018 à 22:30, Thomas a écrit : > > Web forums are much more superior than mailing lists, in any possible > direction. > There's nothing a mailing list can provide a forum can't, since it doesn't > exclude email notifications. > However, there's loads of benefits a forum provides a mailing list can't > catch up with. > That's the reason why mailing lists are disappearing. I respectfully don't agree. Web forums truly have the advantage of being an archive of previous conversations, making it easy for new subscribers to browse or search and partially read previous content at first. There are a number of third-parties aggregators that do the same for mailing-lists, but indeed such an archive run by the mailing-list owners themselves is probably superior if it can at the same time be used by web forums lovers to read and participate in the conversation group. There is nothing right in trying to persuade people that one's idea is everybody's wish and best for them all. People of a certain age know that History, as well as on a much less tragic way, computer industry, has too many examples. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] [sqlite] Mailing list shutting down...
> Le 14 juin 2018 à 22:23, Thomas a écrit : > >> Mailing list messages are easily filtered. >> I have one mailbox for each mailing list I subscribe to, and I read through >> the messages in list order, which makes it easy to mentally switch gears >> from one project to the next. > > Most people only have one mailbox. I presume you're referring to folders. > > >> If one project gets out of hand for a while, I can mark only that one >> mailbox as “read” without declaring email bankruptcy on all my other email. > > Forum software offers the very same functionality but that's not the direct > purpose of it. In a mailing list you're either "in" or "out". A forum > provides all possible options. I routinely follow and participate in about 18 mailing-lists. They're all conveniently aggregated in folders, which is done automatically by rules applied by my IMAP mail server upon arrival.That's comfortable and I have all of it through a single user interface: my email reader. I can easily full-text search on a folder, some or all of them. With a decent email reader and a mailbox managed by a decent, standard compliant, IMAP server, these actions are effective (server-side filtering for instance). I can also set expiration rules to automatically purge older messages, depending on the folder. I can't even imagine myself finding the time and will to visit about 12 to 15 different URLs, user interfaces, to browse and read what might interest me. And then face as much different interfaces to reply conveniently. The right solution to please every wishes is to have a perfectly integrated dual-interface system where the mailing-list and the webforum is *one*. Displaying, encouraging proper threading on the webforum, respectfully matching the email threading. And reciprocal. Such that it wouldn't make any difference if I post per email, reply/quote per email or through the webforum. I'd be free to ignore the existence of the webforum as much as you could ignore it is a mailing list at the same time. Each subscriber electing to have the content delivery additionally per email, or not. Any webforum solution with an email notification mechanism in the style "hey someone just posted a reply" or "there have been 122 posts since your last visit" is useless to me. This is worse than not getting email at all: it pollutes the mailbox with contentless and countless reminders, yet doesn't solve the time-consuming issue to having to pull information from one webforum at a time, using all their different user interfaces. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Perception of Fossil
Le 16/06/2018 à 17:05, Eduardo Morras a écrit : I partially disagree. If you allow anonymous people to pull / commit / merge data to your 'central repository', you can get easily spammed. If I pull-request 100 images of 10MB your system will go down. Multiply it by several 'funny guys' on more than one repository and fossil credibility / reputation will be -1. The idea is not to allow anonymous to commit or merge. It’s to allow anonymous to send a bundle that doesn’t modify the code or the history. The package is a way to ask to commit some code. But yes, there should be a way to limit the bundle size and a way to limit the overall size allowed to store these bundles. And obviously, an option to disable the feature would be useful too. Olivier ___ 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] Using bundles for pull requests
Another issue with bundles: "push requests" derived from local private branches. It may be not only the receiver of a "push request" to decide to import only the final "accumulated patch", without all the detailed "commit-by-commit" history. It may also be the submitter to decide to keep the development history for a "push request" in a local private branch, and only submit the final "accumulated patch", without the full history of all the trials, reverts, and minor coding style and typo fixes. So, the intuitive way for this would be to merge their local private branch into a new branch derived from the same root, and export the new branch to a bundle with the "--standalone" option (the "push request" feature will probably do this, by default). But importing this bundle into the upstream repository, lacking all the knowledge of the local private branch, may have undesired effects. In one of my tests, the /bloblist showed an "unknown" artifact of 0 bytes, with the UUID being one of those listed in the P-card of the imported check-in. Also, not sure if this might lead to problems with future merges, if the parents and merge ancestors referenced by the imported check-in cannot be found in the upstream repository. Bundles are not patches that can be applied freely and flexibly, but tend to rely on the full repository history. --Florian ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
