Re: [fossil-users] TinyMCE for editing wiki pages

[Paul Hammant]

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

> 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

Re: [fossil-users] REST API and client for same

[Paul Hammant]

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] REST API and client for same

[Paul Hammant]

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

[Paul Hammant]

>
>
> 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] Fossil as an app server?

[Paul Hammant]

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

Re: [fossil-users] Fossil as an app server?

[Paul Hammant]

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

Re: [fossil-users] Fossil as an app server?

[Paul Hammant]

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

[fossil-users] Fossil as an app server?

[Paul Hammant]

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-scm as an SQLite db with schema/data revision control

[Paul Hammant]

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?

[Paul Hammant]

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?

[Paul Hammant]

> 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] Bitrot defense?

[Paul Hammant]

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

[Paul Hammant]

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

[fossil-users] Bitrot defense?

[Paul Hammant]

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] Merge tracking tests in a blog entry, some questions

[Paul Hammant]

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

[Paul Hammant]

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

Re: [fossil-users] Merge tracking tests in a blog entry, some questions

[Paul Hammant]

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

[fossil-users] Merge tracking tests in a blog entry, some questions

[Paul Hammant]

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