Re: [fossil-users] Merge tracking tests in a blog entry, some questions
> >- The 'open' step. > >> > These result from the fact that a single Fossil repository can have > >> multiple simultaneously open check-outs. To do the same in something > like Git, you have to have multiple clones. > Super cool feature, I agree. > In SQLite development, we *very* often have multiple branches and/or > >> historical versions of SQLite open and under development > >> simultaneously, and so having the ability to host these multiple > check-outs from a single repository is important. > Yes, that's nice. Specifically, workspace (optionally) *not* 1:1 with clone. > > >1. How do I choose a non 'trunk' name for the initial branch? My test > >> >needed a branch called 'one' and another 'two'. > >> > You can change the branch to which any check-in belongs > >> after-the-fact. Simple bring up the ui ("fossil ui") and click on the > >> link for the check-in, then on the "Edit" link. Then use the "Make > >> this check-in the start of a new branch named: __" option. This > >> can also be done from the command-line, though I cannot tell you how > off the top of my head - I'd have to go look > I can live without know the command line fu for that, for the sake of a blog series. Might be nice as a low priority feature request for 'init': fossil init .fossilDB --default-branchname one > > >2. Is it possible to do the --record-only merge thing subversion does > >> >(Git calls it ‘strategy-ours’, and in Perforce it is ‘accept yours’) > ? > >> > I'm not familiar with that feature. What does it do? Does it pretend > >> that one branch has been merged with other without actually changing > >> any of the code? I don't recall ever having had a need for such a > thing? Can you suggest a scenario where it might be useful? > There are plenty of useful scenarios, but the biggest is 'maintained divergence' - http://paulhammant.com/2013/04/02/maintained-divergence/. That, and three years ago I made a config system with a colleague resting on SCM for production use (as opposed to developer use) - https://github.com/paul-hammant/app-config-app that it would be nice to return to. >3. Where does Fossil top out? > >> > SQLite database files top out at around 140 Terabytes. There are, > >> however, some operations that use time proportional to the size of the > database. "clone" and "rebuild" come quickly to mind. > Impressive. > > Performance problems come about more due to the number of files in a > >> single check-out. Most projects have a few thousand source files, for > which Fossil works great. > That's my use case, too. Note, Git and Subversion) have 'sparse-checkouts', but not 'sparse clones'. Perforce's git-fusion adapter can do sparse clones (kindof a holy-grail). You think you've cloned the whole repo, say, but perforce silently masked out a set of directories (not necessarily at root). Perforce had fine-grained R+W permissions for that, as well as client-spec globbing that Google used to the nth degree - http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/ Note, Google replaced Perforce as their backend (their one big trunk) in 2012 with some in-house perforce-alike thing, but I did not know at the time of writing the above article. In terms of build systems - Facebook's Buck and Google's Bazel are in the image of Google's internal Blaze, and that had the ability to deliberately manipulate 'sparse checkout' settings. > - Paul ___ 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] Merge tracking tests in a blog entry, some questions
Thanks Stephen & Richard. ___ 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] Merge tracking tests in a blog entry, some questions
Nice writeup Ron. Worth putting up online for posterity (I mean a page with a URL rather than left in web-mail). It certainly provides some additional nuggets of information to the #1 ranked quick start :) I have a small lament. Specifically that casual users can't (optionally) clone and make working-copy in one go. $ fossil clone --quiet --working-copy-too --replica-in-dotfile-please http://www2.fossil-scm.org/ fossils_own_source $ cd fossils_own_source $ ls -al .fossil -rw-r--r-- 1 paul staff 38551552 Jun 19 08:50 fossilRepo.fossil Indeed I seem to have gotten myself in a mess with Fossil's (v1.34) own checkout: $ mkdir playing_with_fossil $ cd !$ cd playing_with_fossil $ pwd /scm/oss/playing_with_fossil $ fossil clone http://www2.fossil-scm.org/ fossilRepo.fossil Round-trips: 7 Artifacts sent: 0 received: 33878 Clone done, sent: 1688 received: 33007963 ip: 66.228.42.154 Rebuilding repository meta-data... 100.0% complete... Extra delta compression... Vacuuming the database... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 server-id: 8b598a187666c8c1d32e6ad19cefd11e2cf19a20 admin-user: paul (password is "e7e2c6") $ ls -al fossilRepo.fossil -rw-r--r-- 1 paul staff 38551552 Jun 19 08:52 fossilRepo.fossil $ mkdir wc $ cd wc $ fossil checkout ../fossilRepo.fossil Fossil internal error: repository does not exist or is in an unreadable directory: /scm/oss/fossilsOwnRepo That last directory or file - /scm/oss/fossilsOwnRepo - I deleted that yesterday. I don't know why attempts to checkout are referring to it. Is there something in ~/.fossil that's residual about local repos / replicas and affects all open shells going forward? Guidance appreciated. - Paul On Sun, Jun 19, 2016 at 4:39 AM, Ron W <ronw.m...@gmail.com> wrote: > On Sat, Jun 18, 2016 at 1:21 PM, Paul Hammant <p...@hammant.org> wrote: > >> Curiosities: >> >>- Having a database name rather than just a .git or .svn folder >>convention >>- The 'open' step. >> >> Fossil and SVN are more similar than you seem to think. > > Fossil's "open" command is much like SVN's "checkout" command. Both take a > path to a repository. The difference being that Fossil expects a local > database file while SVN expects an URL to the repository, which SVN treats > as remote, even if it is local. This is because SVN clients all work from a > central repo, while Fossil works with a local repo that might be a copy of > a remote/central repo. And, like SVN's "checkout" command, "open" also > checks out files into your working copy. > > Also, like SVN, when a working copy is created, a .fossil file is created > in the base folder of the working copy. (SVN uses a folder, Fossil uses a > database file.) > > Fossil's "update" is pretty much the same as SVN's "update". > > Fossil's "checkout" is a bit different. While it fetches the specified > version of files, it does not attempt to merge with local changes. > > So, like SVN, Fossil allows multiple working copies from the same repo. > But Fossil working copies are associated with a local repo while SVN > working copies are associated with a remote/central repo. > > The local Fossil repo is what might be associated with a remote/central > repo. A pull, push or sync command done from any of the working copies will > cause the associate repo to interact with the remote repo. SVN commands > always interact directly with the remote repo, so SVN doesn't have pull, > push or sync. > > Also, when you commit from one local working copy, you can then update > from another local working copy without doing a pull, push or sync. Remote > working copies won't be able to update to your commit until pull, push or > sync (as appropriate) is done to get the commit transferred. > > git, on the other hand, every working copy has it's own local copy of the > repo, so each local working copy is completely independent, just as a > remote working copy would be. To transfer commits between git working > copies - local or remote - you have to pull, push or sync. > > From my point of view, Fossil provides the best of a DVCS with the best > features of SVN or other non distributed VCS. I can perform VCS operations > "off line", even with multiple working copies (with only one local copy of > the repo), then still be able to easily sync to a remote repo once online. > > > ___ > 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] Merge tracking tests in a blog entry, some questions
Hi there. I did a blog entry on Fossil, and how it is able to handle a cherry-pick merge scenario that breaks subversion: http://paulhammant.com/2016/06/18/subversion-merge-limitations-not-in-fossil/ Learning curve for Fossil - about an hour. Curiosities: - Having a database name rather than just a .git or .svn folder convention - The 'open' step. Pleasant surprises: - when making a branch, having a 'where from' basis (which I hope is retained) Questions: 1. How do I choose a non 'trunk' name for the initial branch? My test needed a branch called 'one' and another 'two'. 2. Is it possible to do the --record-only merge thing subversion does (Git calls it ‘strategy-ours’, and in Perforce it is ‘accept yours’) ? 3. Where does Fossil top out? Nvidia, Pixar and Google pushed Perforce to multi-terrabytes of HEAD revision, metadate and history. With submodules, git doesn't like to be able 1GB (size of clone), though some field reports suggest 7GB works too. - Paul ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bitrot defense?
Bitrot - http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ - data in SSD or HD being corrupted by (say) nutrinos over time. See also a guy/gal lamenting their corrupted photo collection - https://blog.barthe.ph/2014/06/10/hfs-plus-bit-rot/ Anyway, will two fossil installs replicating each other do anything with merkle trees to heal such bitrot silently and in the background? - Paul ___ 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-scm as an SQLite db with schema/data revision control
Adam, > So basically, this could be a distributed, multi-user database. > Each user would have a local copy (fast access) with their own branches > (write control) but there could be data sharing through merges. (This > probably sounds obvious to fossil users but think about it from the > perspective of sharing database content rather than sharing a pile of > files (source code). > If you want to use a generic SCM for versioning of *app data*, you should really think of a document store, where a schema-less document (JSON) is in a file ins source-control, and you're bumping HEAD revision in your app. That could be on your fork, or a shared repo. If your fork, then merge plays a part later on. For less merge clashing because of whitespace diffs, YAML or TOML could be better formats. There's plenty of examples online for this sort of thing. Hit me up off the list if you're wanting more. Here's me writing about "very small data" - http://paulhammant.com/2012/11/20/very-small-data/ - which might have a bearing on your thinking. - Paul ___ 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] Bitrot defense?
OS/ File system repair of a large image file (such as fossil's) is the way ahead? I say that because I would imagine it better implemented as a fossil background activity communicating with a replica elsewhere. Sent from my iPhone > On Jun 28, 2016, at 8:30 AM, Karel Gardas <gard...@gmail.com> wrote: > > You need to use something like RAID1 setup with N drives using either > ZFS or btrfs. If you are on dragonfly bsd probably hammer does that > too. Also backup and scrub your disk array quite often... > > Ah, just found out that zfs/btrfs is also cited by the article so you > already know that... > >> On Tue, Jun 28, 2016 at 1:09 PM, Paul Hammant <p...@hammant.org> wrote: >> Bitrot - >> http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ >> - data in SSD or HD being corrupted by (say) nutrinos over time. See also a >> guy/gal lamenting their corrupted photo collection - >> https://blog.barthe.ph/2014/06/10/hfs-plus-bit-rot/ >> >> Anyway, will two fossil installs replicating each other do anything with >> merkle trees to heal such bitrot silently and in the background? >> >> - Paul >> >> ___ >> 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bitrot defense?
> > > Fossil *could* be modified to self-repair. It has the info it needs to do > so. > > But then, why bother in a world where you have things like ZFS, which can > protect not only your Fossil repos, but also everything else you hold dear? > So say the's an old version of a PNG that's corrupt in replica-a. It is four versions back from tip/head by that's academic, In replica-b it is OK. There's three commits/pushes a minute to both replica-a (and b by implication) which are now at 6GB in size, because this is a busy hypothetical team. So somehow Btrfs or ZFS know Fossil well enough to repair a small section of a moving target? - Paul ___ 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] Bitrot defense?
Nice article. Short answer is yes, ZFS will heal a file regardless of size or level of activity on it, then. Not only that, but it would be a recommended configuration if you want to *rule out* bitrot/corruption for the the likes of "Need help /tips SQLITE_CONSTRAINT: abort at 42" (this mail list). - Paul On Wed, Jul 6, 2016 at 6:14 AM, Kees Nuyt <k.n...@zonnet.nl> wrote: > [Default] On Wed, 6 Jul 2016 05:02:40 -0400, Paul Hammant > <p...@hammant.org> wrote: > > > ZFS, Btrfs could repair a Fossil database inflight, and without hiccup? > > Tell me a little more - it would repair sectors, blocks, segments of the > > whole Fossil image? Or the whole image? It seems that replacing the > whole > > image would be wrong, and replacing sectors/blocks/segments/sections > would > > be impossible if you want Fossil to not be corrupt in some other way. I > > wrote that because "data being checksummed" is ambiguous. > > Please read: > > https://blogs.oracle.com/timc/entry/demonstrating_zfs_self_healing > or any other article on ZFS and self healing. > > -- > Regards, > > Kees Nuyt > > ___ > 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] Bitrot defense?
> Those filesystems don’t need to know Fossil’s internals at all. >Self-repair only requires checksums and redundancy. If one checksum doesn’t match the contents of the data being checksummed, another copy of the data is checked, and if its contents match the checksum, it is presumed to be the correct one, so the bad copy is overwritten with it. ZFS, Btrfs could repair a Fossil database inflight, and without hiccup? Tell me a little more - it would repair sectors, blocks, segments of the whole Fossil image? Or the whole image? It seems that replacing the whole image would be wrong, and replacing sectors/blocks/segments/sections would be impossible if you want Fossil to not be corrupt in some other way. I wrote that because "data being checksummed" is ambiguous. In summary you're saying that the FS corruption checking and healing is just fine. > Fossil could do the same by comparing the local copy data against its local checksum, and if that doesn’t match, ask the server it most recently sync’d against for its copy. I'm confused - you think Fossil doing it's own bitrot/corruption checking/repair is a thing that is possible/good? - Paul ___ 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 as an app server?
Thanks Joe, thanks Stephen. Joe, Here's a "seatmap" app I made using CouchDB - http://paulhammant.com/2015/12/21/angular-and-svg-and-couchdb/. It works with CORS enabled. In the new Serverless era ( https://martinfowler.com/articles/serverless.html - Mike is a buddy and former colleague of mine) things like CouchDB make perfectly usable "backend as a service" (BaaS) technologies. CouchDB allows anon access as well as logged in users (if so configured). In a sophisticated BaaS solution you'll probably want both and something fine grained to support that in the BaaS platform . which probably means some TH1 fu on the server side. Stephen, Nice achievement and great document on the JSON-api usage (and challenges you faced). should be in markdown under source-control of course . What was the name of your GoogleCode application? They all got auto-moved to Github at some point. I'm example orientated and can only really make leaps in understanding after looking a tight solutions :) - Paul On Wed, Mar 29, 2017 at 10:45 PM, Joe Mistachkinwrote: > > If you compile Fossil with TH1 docs & hooks support and with Tcl > integration > enabled (like I compile it), it makes quite a reasonable server for running > server-side scripts written in TH1/Tcl. > > -- > Joe Mistachkin @ https://urn.to/r/mistachkin > > ___ > 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] Fossil as an app server?
Are you sure there's not some no-frills way of getting at what used to be on Google code - e.g. https://code.google.com/archive/p/majesticuo/source/default/source ? On Thu, Mar 30, 2017 at 7:01 AM, ng0 <contact@cryptolab.net> wrote: > Paul Hammant transcribed 4.8K bytes: > > Thanks Joe, thanks Stephen. > > > > Joe, > > > > Here's a "seatmap" app I made using CouchDB - > > http://paulhammant.com/2015/12/21/angular-and-svg-and-couchdb/. It works > > with CORS enabled. In the new Serverless era ( > > https://martinfowler.com/articles/serverless.html - Mike is a buddy and > > former colleague of mine) things like CouchDB make perfectly usable > > "backend as a service" (BaaS) technologies. CouchDB allows anon access as > > well as logged in users (if so configured). In a sophisticated BaaS > > solution you'll probably want both and something fine grained to support > > that in the BaaS platform . which probably means some TH1 fu on the > > server side. > > > > Stephen, > > > > Nice achievement and great document on the JSON-api usage (and challenges > > you faced). should be in markdown under source-control of course > > . What was the name of your GoogleCode application? They all got > > auto-moved to Github at some point. I'm example orientated and can only > > If only.. You had the option to export them at free will. That sadly > also means that in the cases where upstream developers went on hiatus > long enough to miss the shutdown we now have to search for the correct > upstream. libmp4v2 is one of the packages which makes our job as package > maintainers harder than it has to be. > > > really make leaps in understanding after looking a tight solutions :) > > > > - Paul > > > > On Wed, Mar 29, 2017 at 10:45 PM, Joe Mistachkin <sql...@mistachkin.com> > > wrote: > > > > > > > > If you compile Fossil with TH1 docs & hooks support and with Tcl > > > integration > > > enabled (like I compile it), it makes quite a reasonable server for > running > > > server-side scripts written in TH1/Tcl. > > > > > > -- > > > Joe Mistachkin @ https://urn.to/r/mistachkin > > > > > > ___ > > > 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 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] Fossil as an app server?
Fossil being comfortable serving up HTML is well known. Could I serve up (say) an AngularJS app that spoke HTTP back to the Fossil server to effectively do CRUD operations on a JSON document at HEAD revision? I see that Fossil doesn't follow PUT/POST verbs*, but that doesn't really matter if the JavaScript app can craft URLs to match APIs. * see the bottom of https://www.fossil-scm.org/xfer/doc/tip/www/aboutcgi.wiki Does anyone know of an example app somewhere that shows it all work? Like a "Hello World" of any JavaScript app that does at least C R and U of CRUD with Fossil as the backing store? Thanks, - Paul ___ 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 as an app server?
Or maybe examples of curl commands that can demonstrate CRUD operations against a Fossil repo HTTP interface? ___ 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] REST API and client for same
> > > I have little need for such a thing myself, so I’m just throwing this idea > out there for anyone who thinks it looks like a good itch to scratch. > I do have a need for this class of use. My thread "Fossil as an app server" (nearly a week ago on this list) is in the same direction. Here's something I made 8/9 years ago - a WYSInWYG wiki on top of Subversion using it's auto-increment feature - https://www.youtube.com/watc h?v=WfjK0Pb6IIM. and GET/PUT (and an application in the middle). It bumped head revision and did nothing for clash detection. I'm not going to breath life into that again. Here's where I'm going more recently - 0. Here's the "seatmap" app I made using CouchDB again - http://paulhammant.com/2015/12/21/angular-and-svg-and-couchdb/. It works with CORS enabled directly from JavaScript to CouchDB - REST-centric PUT/GET of a resource. CouchDB isn't a SCM, but it could be with some enhancements. Prospective users of CouchDB should know it is insecure in ways that security experts roll their eyes - https://blog.couchdb. org/2017/01/24/couchdb-ransom-notes/. 1. http://paulhammant.com/2016/06/26/using-rhodecode-and- angular1-as-an-editor-for-a-config-as-code-system/ - the last incarnation of a thing I'm still chasing. An Angular 'form' - directly saving JSON to HEAD revision of a Subversion or Git or Mercurial repo. Heavy lifting courtesy of Rhodecode, which is probably maintaining working copy for me, somehow. While the class of application (SCM backed apps) is what I'm after, there's no REST involved here. 2. Here's me stretching my skills to make a similar editor for Github as a backing store - http://paulhammant.com/2015/06/07/custom-json-editors-for- github/. Again the right class of application, but no REST involved. 3. Going back in time - I coached a new starter (Logan McGrath) at my old company into making a real config editing thing with Perforce as a backing store - http://loganmcgrath.com/blog/2012/11/16/scm-backed-applica tion-configuration-with-perforce/. We wrote this thing, so we sure as shit knew we were maintaining working copy for the client on the server. Right class of application, no REST involved. 4. A pre-cursor for #3 - http://paulhammant.com/2012/ 08/14/app-config-using-git-and-angular/ - using Git a the backing store My nirvana is Fossil upgraded to allow discrete CRUD operations over HTTPS. I'd prefer REST, but will live with anything that I can perform from JavaScript in a page that was a] served up (with mime types) from the same HTTPS interface, or b] from another site/server and interoperating with Fossil resources via CORS. Towards that #0 is the reference that's relevant for the 'ask' now, and #1-#4 are supporting on the class of application, not the precise mechanism (REST or something close enough). I'm pretty sure it's just a question of time until doc-store and VCS convergence happens. As I blog around this topic area, http://paulhammant.com/2012/11/20/very-small-data/ might be interesting too, - Paul ___ 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] REST API and client for same
I don't really need Fossil to become an application server. I just need it to handle CRUD over HTTPS on specific resources, and have configurable permissions for that. Though TH1 scripts exist, I'd not use them, nor anything that purports to be JSP/ASP application scripting model. I'd not need them, if I've shifted my application code to JavaScript. Just like for CouchDB in a "backend as a service" configuration, *in-house non financially critical* *applications* are the type of apps that would fit well. CouchDB implements CORS <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS> which all the modern browsers are savvy with too, and that is a partial answer to XSS/CSRF concerns. Anyway - I'd want everything that CouchDB does in the BaaS <https://martinfowler.com/articles/serverless.html> model, but lose the query capability if I had to. I'd want to gain security features that CouchDB doesn't do by default <https://www.google.com/search?q=couchdb+ransomware> ("AdminParty" and HTTP *off* by default, HTTPS *on* by default). Why VCS - who wouldn't want to be able to checkout documents as a set, perform functions on them, and commit them back as a set, atomically? - Paul - Paul On Tue, Apr 4, 2017 at 2:53 PM, Warren Young <war...@etr-usa.com> wrote: > On Apr 4, 2017, at 11:24 AM, Paul Hammant <p...@hammant.org> wrote: > > > > > I have little need for such a thing myself, so I’m just throwing this > idea out > > > there for anyone who thinks it looks like a good itch to scratch. > > > > I do have a need for this class of use. My thread "Fossil as an app > server" (nearly a week ago on this list) is in the same direction. > > Only in the vaguest sort of way. > > My idea is just that you should be able to replace the fossil binary as a > client with a series of HTTP calls, which lets you replace > fossil-the-client without duplicating all of its internal functionality. > > This idea of turning Fossil into a generic application server is off on a > completely wild tangent from that point. > > While thinking about this sort of thing, consider the XSS problem just > brought up on the mailing list. To me, “generic application server” > implies multiple independent — possibly mutually-untrusting — applications > running on a single platform. So, you’d better solve the XSS problem first. > ___ > 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] REST API and client for same
OK, so I don't think there's any interest in this beyond me :-( On Wed, Apr 5, 2017 at 1:58 PM, Paul Hammant <p...@hammant.org> wrote: > I don't really need Fossil to become an application server. I just need > it to handle CRUD over HTTPS on specific resources, and have configurable > permissions for that. Though TH1 scripts exist, I'd not use them, nor > anything that purports to be JSP/ASP application scripting model. I'd not > need them, if I've shifted my application code to JavaScript. > > Just like for CouchDB in a "backend as a service" configuration, *in-house non > financially critical* *applications* are the type of apps that would fit > well. CouchDB implements CORS > <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS> > which all the modern browsers are savvy with too, and that is a partial > answer to XSS/CSRF concerns. > > Anyway - I'd want everything that CouchDB does in the BaaS > <https://martinfowler.com/articles/serverless.html> model, but lose the > query capability if I had to. I'd want to gain security features that CouchDB > doesn't do by default <https://www.google.com/search?q=couchdb+ransomware> > ("AdminParty" > and HTTP *off* by default, HTTPS *on* by default). Why VCS - who > wouldn't want to be able to checkout documents as a set, perform functions > on them, and commit them back as a set, atomically? > > - Paul > > - Paul > > On Tue, Apr 4, 2017 at 2:53 PM, Warren Young <war...@etr-usa.com> wrote: > >> On Apr 4, 2017, at 11:24 AM, Paul Hammant <p...@hammant.org> wrote: >> > >> > > I have little need for such a thing myself, so I’m just throwing this >> idea out >> > > there for anyone who thinks it looks like a good itch to scratch. >> > >> > I do have a need for this class of use. My thread "Fossil as an app >> server" (nearly a week ago on this list) is in the same direction. >> >> Only in the vaguest sort of way. >> >> My idea is just that you should be able to replace the fossil binary as a >> client with a series of HTTP calls, which lets you replace >> fossil-the-client without duplicating all of its internal functionality. >> >> This idea of turning Fossil into a generic application server is off on a >> completely wild tangent from that point. >> >> While thinking about this sort of thing, consider the XSS problem just >> brought up on the mailing list. To me, “generic application server” >> implies multiple independent — possibly mutually-untrusting — applications >> running on a single platform. So, you’d better solve the XSS problem first. >> ___ >> 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] TinyMCE for editing wiki pages
BSD codebases can use LGPL components/libs without fear of being in violation of license. On Wed, Jun 7, 2017 at 6:10 AM, Richard Hippwrote: > On 6/7/17, Chris Rydalch wrote: > > I tried following the Cookbook page, but haven't had luck getting it to > > work. I assume it's because a lot has changed in the last 8 years, both > > with Fossil and TinyMCE. I tried adapting the instructions, but they > don't > > seem to be applicable anymore. > > > > Does anyone have a recent example repo using TinyMCE to edit wiki pages? > > > > I had never heard of TinyMCE. I checked the webpage and it seems nice > enough. Unfortunately, the license is LGPL, which I think will make > it incompatible with the BSD license of Fossil. Perhaps someone else > can clarify. > > -- > 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users