Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control
On 07/27/2016 10:37 AM, Ron W wrote: > On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen <mailto:han...@riseup.net>> wrote: > > > [The Session Extension](http://www.sqlite.org/sessionintro.html) pointed > out by Eduardo seems to have a lot of potential. > > "The session extension provides a mechanism for recording changes to > some or all of the rowid tables in an SQLite database, and packaging > those changes into a "changeset" or "patchset" file that can later be > used to apply the same set of changes to another database with the same > schema and compatible starting data. A "changeset" may also be inverted > and used to "undo" a session." > --- > Eduardo's description of the SQLite extension only talks about table > data. This would still leave a need for managing schema updates. > Interesting, I didn't interpret it that way. > If this SQLite extension also handles schema updates, then probably no > reason to use tickets. > I suspect it does but I haven't tested that suspicion yet. I've compiled SQLite with support for the Session Extension but section 2.0 of the documentation - "Using The Session Extension" - is empty. > In either case, the actual changesets should be suitable to manage as > files in Fossil. > I suppose when Fossil manages a file, from one version (check-in) to the next it is a diff of some kind that is actually recorded and generating the diff is an internal mechanism that is part of the check-in process. Imagining a custom system for distributed version control of an SQLite database, composed of components harvested from Fossil (but not a standard-off-the-shelf Fossil system), the file being managed might be something like a .dump of the database and the current Fossil diff mechanism could (abstract concept) be replaced with the Session Extension method of generating diffs (changesets). Does anyone know of a [libfossil](http://fossil.wanderinghorse.net) mailing list? Or is it cool to talk about such things here? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] basic usage question - empty directories
Hi, I haven't before used fossil to manage a project. Is there a way to commit empty directories to the repository so the project's directory structure can be preserved and reconstructed? Actually, some of the directories aren't empty but rather their contents are ignored: fsl add --ignore '*.db,*.fossil,*.log,*.mp3' * fsl commit -m "Initial checkin" Is this something simple that I haven't yet discovered in the documentation or am I doing something terribly wrong? Thanks! ___ 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] basic usage question - empty directories
On 08/01/2016 07:25 PM, Steve Stefanovich wrote: > > Create a .fossil-settings directory in the root of your checkout, and in it > add empty-dirs file with relative paths to where you want empty directories > created, fossil add/commit. > Is there documentation for that approach? I can't seem to get it to work. Could you provide an example demonstrating the method, or review my attempt (below) and provide corrections? mkdir test cd test/ mkdir repo mkdir project cd repo fossil init test.fossil cd ../project/ fossil open ../repo/test.fossil touch README mkdir empty1 mkdir notempty1 touch notempty1/foo.tcl tree . |-- empty1 |-- notempty1 | `-- foo.tcl `-- README mkdir .fossil-settings vi .fossil-settings/empty-dirs cat .fossil-settings/empty-dirs ./empty1 fossil add * ADDED README ADDED notempty1/foo.tcl fossil commit -m "Initial checkin" New_Version: 977b2342d05cd9b04fb6a1963fcbb7a96823fe75 ___ 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] basic usage question - empty directories
On 08/01/2016 07:40 PM, bch wrote: > There has been lots of discussion about this over the years > (https://www.google.ca/search?q=fossil-users+empty+directory). > > I personally handle this (and other metadata things like user:group > ownership or permissions (though we now handle --x (executable bit)) I'm guessing this means that file permissions aren't maintained through the check-in/check-out process(?) Do you have a link to --x documentation or can you provide an example? > in a controlling file. Something like a purpose-built makefile or > script that handles this layout, so that -it- can be versioned in > fossil; fossil wasn't/isn't currently designed to handle that sort of > metadata - which *arguably* should be handled in a script as described > above. Fossil can then handle that script as an artifact. > Is there a way to run these scripts automatically after each checkout? ___ 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] basic usage question - empty directories
On 08/01/2016 10:25 PM, Steve Stefanovich wrote: > At the end, you didn't add the empty-dirs file. You need to do 'fossil add * > --dotfiles' or explicitly do 'f add .fossil-settings/empty-dirs', then > commit. Then a subsequent checkout will create the directories. > Thanks. Following John's documentation links (below) led to that basic understanding a little earlier today. I also discovered some other fundamentally important configuration options there. In addition to empty-dirs, my setup also needs ignore-glob and keep-glob to avoid 'add'ing some files and to avoid 'clean'ing some files. Thanks for the help! On 08/01/2016 08:12 PM, John P. Rouillard wrote: > See: > >http://fossil-scm.org/index.html/help?cmd=settings > >empty-dirs A comma or newline-separated list of pathnames. On > (versionable) update and checkout commands, if no file or directory > exists with that name, an empty directory will be > created. > > Also see: > > http://fossil-scm.org/index.html/doc/cd58f59a474c7ef773d1/www/settings.wiki > > look under "Versionable" settings. > ___ 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] basic usage question - empty directories
On 08/01/2016 11:01 PM, Ron W wrote: > On Mon, Aug 1, 2016 at 8:22 PM, Adam Jensen Is there a way to run these scripts automatically after each checkout? > > > My team and I do this as part of the build procedure. Basically, we > treat those as part of the "product" being built, so when we do a "clean > check out", the first run of make will create those directories. We > don't need them before that. > Cool. I've looked at the Fossil project a few times during the last couple of years but I haven't used it before now (now means *today*) so I don't really have a grip on all of its capabilities yet. Subversion has "Repository Hooks" (a program triggered by some repository event); Fossil might have had a similar capability ... worth asking. ___ 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] How to host fossil repositories on web server that supports only FastCGI interface?
On 08/02/2016 05:00 AM, Richard Hipp wrote: > On 8/2/16, John Found wrote: >> I have to move my web site on a server that supports only FastCGI interface. >> Is there an easy way to host fossil repositories on it? > > Fossil only support CGI and SCGI. What web server are you running > that has only FastCGI support. > > When I was looking into alternatives to plain old CGI, I found that > the FastCGI protocol was very complex and hard to implement, whereas > SCGI was quite simple. So I took the simpler approach. Are there > some advantages to FastCGI that I am unaware of? > OpenBSD's [httpd][1] is another FastCGI-only serer. [1]: http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/httpd.8 They use a FastCGI to CGI wrapper server (named [slowcgi][2]) that translates FastCGI requests to the CGI protocol. [2]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/slowcgi/ ___ 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] basic usage question - empty directories
On 08/02/2016 10:57 AM, Ron W wrote: > On Tue, Aug 2, 2016 at 12:26 AM, Adam Jensen <mailto:han...@riseup.net>> wrote: > > > Subversion has "Repository Hooks" (a program triggered by some > repository event); Fossil might have had a similar capability ... > worth asking. > > > With all the right things enabled during build, Fossil can run TH1/TCL > scripts on certain events. But, aside from updating Fossil metadata, can > only notify the "outsife world" by sending an HTTP request to a > specified URL. I am pretty sure the scripts can construct the URL used, > so some information can be encoded in the URL. > > Otherwise, the main mechanism for automated publication of notices is RSS. > So neither the TH1 or the embedded Tcl engine have typical shell-like access the OS? ___ 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] basic usage question - empty directories
On 08/02/2016 02:17 PM, Joe Mistachkin wrote: > > Adam Jensen wrote: >> >> So neither the TH1 or the embedded Tcl engine have typical shell-like >> access the OS? >> > > If the Tcl integration features of Fossil are enabled, the Tcl interpreter > will have full access to the Tcl command set, including any packages that > happen to be installed. > > By default, Fossil will attempt to load the "best" Tcl library found in the > PATH; however, this behavior can be overridden using the FOSSIL_TCL_PATH > environment variable (which can point to a file or directory). Supported > versions of Tcl are 8.4, 8.5, and 8.6. > If I've connected the dots correctly, then it seems that repository events could potentially trigger the execution of Tcl scripts (of arbitrary complexity), and this could effectively be used in a fashion similar to Subversion's "Repository Hooks". Nifty! (Or did I drop the ball somewhere?) ___ 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] Unversioned files.
On 08/30/2016 02:31 PM, Richard Hipp wrote: > A new feature of Fossil (currently unreleased and only available to > people who are willing to recompile the code on trunk) is "unversioned > files". > > https://www.fossil-scm.org/fossil/doc/trunk/www/unvers.wiki Hey, cool. This seems like a move in a good direction. I can imagine scenarios where some files are relevant to a project, and it would be convenient to bundle them into the Fossil database for backup and syncing, but saving the change history of those files doesn't really make much sense. For example, a project might have an associated SQLite database and it might be convenient to have a content .dump of that database and possibly a few Session Extension[1] changesets stored in the repository (and sync'able). [1]: https://www.sqlite.org/sessionintro.html In this case, it seems like the ability to check-in, check-out, and remove these unversioned files from the repository would be needed (for it to make sense). In an example work-flow, perhaps only the most recent database .dump would be kept. After a few chagesets are accumulated and a new common database state is agreed upon, a new .dump could be checked-in and the old dumps and chagesets could be removed (if they're no longer needed). The current implementation doesn't look like it would support this (above) scenario. "Unversioned files are not a part of a check-out. Unversioned files are intended to be accessible as web pages..." ___ 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] Unversioned files.
On 09/02/2016 01:05 PM, Richard Hipp wrote: [snip] > I have the request to optionally include unversioned files in the > check-out. But that is not yet implemented. Super cool. Not to hijack this thread but a next step might be to track, manage, and share items in the file-system that are not actually stored in the repository database file; an example might be media files or HDF5 dataset files. In the example use-case of a media file repository, it could be that Fossil is used to store annotation data such as subtitle files, edit decision lists, playlists, etc. but it also tracks the origins of the media files (which user added which file, when, etc.) and how those media files might be sync'ed (obtain a local copy, omit a local copy, share the local copy, etc.). The media files themselves would be unversioned and stored in the traditional file-system. And not to be too overwhelmingly far out, but at this point one might begin to imagine that the sync function could be extended with torrent-like capabilities. (Too much?) ___ 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] Unversioned files.
On 09/05/2016 03:00 AM, Gour wrote: [snip] > Now, when I got rid of ownCloud and replaced it with something lighter > to sync my calendars/contacts with the phone, I plan to manually cp-ing > media files to my computer and considering to put all those > photos/videos as unversioned files in a Fossil repo. > > I use 64bit Linux (Debian Sid) with XFS filesystem, so wonder if there > are any recommended limit in regard to number of files kep in the repo > and/or size of the Fossil repo? I'm not a software developer so my technical insight into these issues might be dangerously insufficient in some places but a couple of data points gleaned from the web might be relevant to the discussion. (bottom of the page) The two issues that stand out [to me] are: A. The Fossil repository might have a maximum size for any single [check-in] file of around 1 or 2 GB ([2] "Maximum length of a string or BLOB"). B. I suspect the storage requirement will be twice (2x) the data size - the data is stored once in the Fossil database and another copy would exist in the file-system [as a check-out]. In a situation where many large files are being managed, those two issues might become significant. I can imagine broad classes of applications within various scientific endeavors where there could be easily ~5TB of instrumentation data in ~10,000 files. Current technology makes this very cost effective. While the measurement data would probably need to be considered immutable, the file metadata, annotations, analysis scripts, commentary, discussion, issues, etc. would probably undergo heavy edits/revisions. (It would be valuable if there were audit trails within the file management/data-sharing system (i.e., file integrity checks with chain-of-custody-like verification)). Fossil almost does everything that is needed to become a killer app for people who need a consolidated [and comprehensible] method/tool to manage, share, and collaborate around a common data-set (e.g., research groups in university laboratories). There are a couple of other capabilities that would extend the use-case/user-base even further but I suspect I am already too far off the reservation for general toleration. [1]: http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/ch02s04.html -- 2.4. XFS Limits 32 bit Linux Maximum File Size = 16TB (O_LARGEFILE) Maximum Filesystem Size = 16TB 64 bit Linux Maximum File Size = 9 Million TB = 9 ExaB Maximum Filesystem Size = 18 Million TB = 18 ExaB -- And [2]: https://sqlite.org/limits.html -- Maximum length of a string or BLOB The maximum number of bytes in a string or BLOB in SQLite is defined by the preprocessor macro SQLITE_MAX_LENGTH. The default value of this macro is 1 billion (1 thousand million or 1,000,000,000). You can raise or lower this value at compile-time using a command-line option like this: -DSQLITE_MAX_LENGTH=123456789 The current implementation will only support a string or BLOB length up to 231-1 or 2147483647. And some built-in functions such as hex() might fail well before that point. In security-sensitive applications it is best not to try to increase the maximum string and blob length. In fact, you might do well to lower the maximum string and blob length to something more in the range of a few million if that is possible. -- ___ 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] Unversioned files.
On 09/05/2016 05:23 PM, Adam Jensen wrote: > B. I suspect the storage requirement will be twice (2x) the data size - > the data is stored once in the Fossil database and another copy would > exist in the file-system [as a check-out]. I wonder if it would be nifty if Fossil could export a set (or several sets) of files as a FUSE[1] file-system? How well would that enable the case were one might want to arrange their files in various ways (branches(?)) and present [subsets of] the files as various "views" without increasing the storage requirements [significantly] (no duplication of the large files)? [1]: https://github.com/libfuse/libfuse ___ 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] Unversioned files.
On 09/09/2016 10:20 PM, Richard Hipp wrote: > On 9/9/16, Adam Jensen wrote: >> On 09/05/2016 05:23 PM, Adam Jensen wrote: >>> B. I suspect the storage requirement will be twice (2x) the data size - >>> the data is stored once in the Fossil database and another copy would >>> exist in the file-system [as a check-out]. >> >> I wonder if it would be nifty if Fossil could export a set (or several >> sets) of files as a FUSE[1] file-system? > > Already does that. https://www.fossil-scm.org/fossil/help?cmd=fusefs > That's awesome! It might be possible that with only a few tweaks in a few commands that Fossil could be used effectively and smoothly to work with large unversioned data/media files. In my ongoing attempt to better understand the capabilities and constraints of how Fossil might be used to manage large datasets along with their analysis methods and products, I have two additional questions: 1. What is the largest size of any single file that can be checked into a repository? 2. How well will the sync command handle large files? Additionally, and this might not be a reasonable variation of the fusefs command, I've only been playing with it for about ten minutes, but it might be easier to understand and use if there were a couple more options: Usage: fossil fusefs ?options? DIRECTORY Options: --debug -R|--repository REPO*new* There need not be an existing checkout. ?VERSION | --latest?*new* This command uses the Fuse Filesystem (FuseFS) to mount a *READ-ONLY* directory at DIRECTORY that contains the content of all check-ins in the repository. If ?VERSION is specified, the names of files are DIRECTORY/PATH where DIRECTORY is the root of the mount, and PATH is the pathname of the file in the check-in. If not ?VERSION is not specified, the names of files are DIRECTORY/checkins/VERSION/PATH where DIRECTORY is the root of the mount and VERSION is any valid check-in name (examples: "trunk" or "tip" or a tag or any unique prefix of a SHA1 hash, etc). ___ 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] Unversioned files.
On 09/10/2016 01:31 PM, Adam Jensen wrote: [snip] > 1. What is the largest size of any single file that can be checked into > a repository? [snip] I did some tests with Fossil trunk, checked-out and compiled today. too big: dd if=/dev/urandom of=1GB-file.test bs=64M count=16 too big: dd if=/dev/urandom of=64Mx15-file.test bs=64M count=15 *works*: dd if=/dev/urandom of=64Mx14-file.test bs=64M count=14 answer: somewhere between 939524096 and 1006632960 bytes ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fusefs issues
fossil version used for this test: checkout: 871f978d9b080403b73408858a63353ddaaf85a3 2016-09-10 20:01:51 UTC I did some tests with fusefs[1] today. [1]: https://www.fossil-scm.org/fossil/help?cmd=fusefs Some issues: 1. Unversioned files (e.g., fossil unversioned add 128MB-file.test) don't show up in the fusefs directory. I think this is a work-in-progress but it's worth mentioning here (for completeness/posterity). 2. Timestamps on the fusefs directory's files are all: Dec 31 1969 3. Performance is currently very poor. With binary files created like this: dd if=/dev/urandom of=16MB-file.test bs=8M count=2 dd if=/dev/urandom of=24MB-file.test bs=8M count=3 Then added to the repository like this: fossil add 16MB-file.test fossil commit -m "small binary file for testing" Then the repository was mounted like this: fossil fusefs ~/fslmnt cd ~/fslmnt/checkins/trunk Performance comparison between the fusefs directory and the regular fs check-in/out directory: | time md5sum| fusefs| fs | |+---+--| | 8MB-file.test | 0m2.987s | 0m0.052s | | 16MB-file.test | 0m13.745s | 0m0.115s | | 24MB-file.test | 0m30.594s | 0m0.163s | | 32MB-file.test | 0m52.830s | 0m0.195s | I killed a in-progress `time md5sum 768MB-file.test` after ~30 minutes. Then it's unmounted like this: fusermount -u ~/fslmnt ___ 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] Unversioned files.
On 09/11/2016 05:41 AM, Stephan Beal wrote: > On Sep 10, 2016 19:31, "Adam Jensen" <mailto:han...@riseup.net>> wrote: >> 1. What is the largest size of any single file that can be checked into >> a repository? > > effectively limited by system memory: fossil needs approx. 2-3x the > file's size (concurrently in RAM) to create/apply deltas. Does it seem reasonable to assume that unversioned files will not have those (2-3x) memory requirements? Also, do you suppose the *initial check-in* [of typical versioned files] involves that kind of memory usage (2-3x)? >> 2. How well will the sync command handle large files? > > it syncs whole blobs at a time, which are normally (for most versions of > a file after the first) highly efficient/tiny deltas. If a blob is ~1GB, will the data transfer mechanism hang in there and get the job done? I found this page: https://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki which might answer my question after I digest it all (probably requiring some research (I'm not a Computer Scientist or Software Engineer)). But there was something, somewhat unrelated, on that page that did stand out. It says: ''' 5.4 Unversioned File Sync "Unversioned files" are files held in the repository where only the most recent version of the file is kept rather than the entire change history. Unversioned files are intended to be used to store ephemeral content, such as compiled binaries of the most recent release. ''' The phrase "ephemeral content" is a bit disconcerting. It suggests values and attitudes towards this data which will probably be reflected in the requirements, specification, and implementation of the software. In the use-case I have in mind, this data would be "immutable content" and should be considered precious. The goals would be to avoid accidental loss and/or corruption. It isn't a low-value, fleeting scratch-pad that would be thrown away on a regular basis. Perspective makes a difference in what gets built into a system, and how it gets built... ___ 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] Unversioned files.
On 09/11/2016 01:54 PM, Stephan Beal wrote: > On Sep 11, 2016 18:18, "Adam Jensen" <mailto:han...@riseup.net>> wrote: [snip] >> ''' >> 5.4 Unversioned File Sync >> >> "Unversioned files" are files held in the repository where only the most >> recent version of the file is kept rather than the entire change >> history. Unversioned files are intended to be used to store ephemeral >> content, such as compiled binaries of the most recent release. >> ''' >> >> The phrase "ephemeral content" is a bit disconcerting. It suggests >> values and attitudes towards this data which will probably be reflected >> in the requirements, specification, and implementation of the software. >> >> In the use-case I have in mind, this data would be "immutable content" >> and should be considered precious. > > That's not, as i understand it, the intention of unversioned filed. > Anything "important" needs to be checked in (versioned). Unversioned > files are primarily intended for hosting pre-built binaries and such. We might not be intersecting on this point; a perspective difference, I suspect. What I am suggesting is that the current intention of unversioned files might need be slightly tweaked to encourage an additional use-case where the repository supports the organization and management of critical data (immutable; a snap-shot of reality; large binary files) in addition to highly revised text files such as data analysis scripts, annotations, and documentation. Use of the unversioned files facility for storage and management of fleeting, intermediate files is also valuable. Quoting Chancellor Palpatine, I suggest we "embrace...a larger view" of unversioned files. On the other hand, it is still unclear [to me] if Fossil can be used this way. Once more complete unversioned files functionality is available, I can answer some of my questions through tests of the system. The critical points of interest are: 1. Maximum single unversioned file size. 2. Repository performance and integrity as overall size increases. 3. FuseFS performance. 4. Sync performance/reliability/usability. Once I have a better idea of these various characteristics and constraints, then it should be possible to estimate where Fossil might be a reasonable solution and where some other approach is needed. ___ 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] Unversioned files.
On 09/11/2016 04:42 PM, Scott Robison wrote: > I may not be understanding you, but from my point of view, it already > does what you want by supporting versioned files that you simply never > change. For example, you could have a repo that has a structure along > the lines of: > > /root/static-data/ -> a place to store lots of big binary blobs that you > don't intent to ever modify. > > /root/dynamic-data/ -> a place to store things that you want to track > the history for > > Is this inadequate? If so, how or why? My impression is that with a different class of files, the operations, interface, and underlying implementation can be specialized for the qualities, characteristics, and various needs that are peculiar to that class. For example, an unversioned file might avoid some of the CPU, memory, and/or storage requirements that are involved in versioned files. Also, I imagine there might be some specialized commands and alerts associated with the two major use-cases for unversioned files (critical immutable data, and temporary intermediate data). Ultimately, I suppose the purpose of a tool like Fossil is to assist in the management of complexity. Differentiation and specialization seems like a fundamental part of that. But yeah, my tests all currently make use of the versioned file class for storage. ___ 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] Unversioned files.
On 09/11/2016 06:38 PM, Scott Robison wrote: > Of course, adding differentiation and specialization increases > complexity, so it can be a tricky balancing act. We, as a species, have already gone down that rabbit hole. ___ 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] Unversioned files.
On 09/11/2016 05:30 PM, Stephan Beal wrote: > And i would argue against it as falling well out of scope for an SCM ;) I'm okay with that. ___ 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] Unversioned files.
On 09/12/2016 02:55 PM, Ross Berteig wrote: > Clumsy, perhaps, but it would work today. Thanks. The `fossil fusefs ...` performance kills the possibility of using Fossil as a large binary file repository manager. I find myself casually reading "Practical File System Design"[1] and the HDF5 Specs[2] and generally imagining what the requirements for a modern [instrumentation data] repository might be. If anyone wishes to discuss such a thing or otherwise share ideas, they are welcome to contact me. [1]: https://ia600404.us.archive.org/29/items/practical-file-system-design/practical-file-system-design.pdf [2]: https://www.hdfgroup.org/HDF5/doc/Specs.html ___ 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] Incremental import breaks repo.
On 09/16/2016 06:54 PM, Nickolas Lloyd wrote: > see my email on fossil-dev for reference "The current archive is only available to the list members."[1] [1]: http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-dev Is that unusual for an open-source project? (Not that I am opposed to it). There seems to be plenty of opportunities (need) for development in socio-technical systems for modern [information age] projects. (Though, there might be a bit of a bootstrapping problem). I am somewhat foreign [in personality/psychic-architecture] to the anarchy/mosh-pit community process (typical of open-source mailing lists, Internet forums, etc.), is it so prominent because it is simple to set up or because it is effective? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] TH1 and/or Tcl
Is TH1 required to run Tcl scripts? Are there any examples of Tcl use-with/extensions-of Fossil? I am having some trouble sorting out the documentation and determining the build options that would enable exploration. The build page[1] might be out of date/sync with the build options. [1]: https://www.fossil-scm.org/fossil/doc/trunk/www/build.wiki "To enable the native Tcl integration feature feature, add the --with-tcl=1 and --with-tcl-private-stubs=1 options." vs. './configure --help' -- --with-th1-docs Enable TH1 for embedded documentation pages --with-th1-hooks Enable TH1 hooks for commands and web pages --with-tcl=path Enable Tcl integration, with Tcl in the specified path --with-tcl-stubs Enable Tcl integration via stubs library mechanism --with-tcl-private-stubs Enable Tcl integration via private stubs mechanism -- And this page: https://www.fossil-scm.org/fossil/doc/trunk/www/th1.md#tclEval says: "TH1 tclEval Command This command requires the Tcl integration feature. tclEval arg ?arg ...? Evaluates the Tcl script and returns its result verbatim." Does this mean that '--with-th1-hooks' is needed to access a full Tcl implementation? (Is the TH1 interpreter required to invoke the Tcl interpreter?) And [being more explicit than the available documentation], I've discovered that the "path" in '--with-tcl=path' is the location of the "tclConfig.sh" file. For example, I use, '--with-tcl=$HOME/.local/lib'. Two or three beginning to end examples for each, TH1 use and Tcl use would be tremendously valuable. ___ 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] Cutting fossil repository
On 10/08/2016 02:23 PM, Zeev Pekar wrote: > Ok. I understood the consequences - I'll operate on a copy of a repo. So > could you, please, provide the two examples anyway? *snide humor alert* The reluctance of some programmer communities to provide examples has always surprised me. I think documentation would be much more effective if there were comprehensive examples throughout. It seems like those comprehensive examples could be written in a way such that they could be executed as part of the test suite, mostly as a way to verify that the documentation is still in sync with the source. But I come from an electrical engineering education where the goals are to create clear, concise understandings in the most efficient and effective way. Open source software communities seem to have different values/cult'ure. ___ 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] Cutting fossil repository
On 10/08/2016 06:40 PM, Richard Hipp wrote: > I do not know how to make the documentation any clearer. It's something I've been thinking about [in general] for a while and I just used this opportunity to inject the idea into the Fossil community. This seems like the sweet spot with TCL on one side (terrible documentation/organization) and SQLite on the other (stellar software engineering). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Pedagogy Think Tank or Documentation Framework RFC
Given the vast technical resources that are available (and becoming available), documentation creation and refinement seems like a keystone technology. Dedicating weeks or months to evaluate a piece of technology is increasingly becoming a less viable practice. It's something that I've thought about occasionally during the last year, and I recall making plenty of notes on the subject but those notes are buried in an ~30GB pile of files with other notes. (I record my contemplative, speculative, insightful notes in speech form in audio/mp3 files). I've noticed that "Fossil is a distributed NoSQL database"[1]. [1]: https://www.fossil-scm.org/fossil/doc/trunk/www/theory1.wiki And that there are "fourteen application-defined SQL functions and two table-valued functions that are useful for managing JSON content stored in an SQLite database"[2]. [2]: https://www.sqlite.org/json1.html [1] is not easy to find, and [2] is not easy to understand or use. But with this it seems like I could create annotations for the multimedia data, stored in plain text files in JSON format. Those JSON files could be periodically scraped and assimilated into an SQLite database and then used to search/mine the multimedia corpus. If the JSON files are under distributed revision control, multiple people could create/modify annotations (this probably doesn't apply to my notes but the technique could be applied to any media archive). Anyway, the point is that this would be a nifty little set of scripts utilizing Tcl/Tk-SQLite-Fossil that would be tremendously useful [to me] and would be well within my ability to put together,,, if there were a different quality and style of documentation/reference-material. It's a little ironic that I don't have access to my notes on documentation style, structure, and generation methods because the current documentation is impeding the development of the tools I need to search the notes. Good times. Off the top of my head, and following Unix man page style somewhat, what if commands were documented like this: Relevant Definitions Description Example Explanation Rationale Were the Example is comprehensive and provides a complete context and is a demonstration of the 'best practices' and conventions. (A picture is worth a thousand words, so is an example/demonstration. Let people see it work. Give them what they need to experiment with it). If the Example is executable with a known outcome, its execution could be included (automated) in the Release Engineering process to determine the points where the documentation needs to be updated so that it maintains traction with the core software. The other big component is community involvement, but I suspect this post is already too long to digest. Has anyone else thought about these issues? ___ 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 on HN
On 10/09/2016 09:31 PM, Richard Hipp wrote: > https://news.ycombinator.com/item?id=12673229 These are probably significant decision points for a lot of people: "My intent is to continue personally supporting and maintaining Fossil for at least three more decades." https://youtu.be/Jib2AmRb_rk?t=4m33s ___ 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 on HN
On 10/10/2016 08:12 AM, Adam Jensen wrote: > On 10/09/2016 09:31 PM, Richard Hipp wrote: >> https://news.ycombinator.com/item?id=12673229 > > These are probably significant decision points for a lot of people: > > "My intent is to continue personally supporting and maintaining Fossil > for at least three more decades." > > https://youtu.be/Jib2AmRb_rk?t=4m33s Along the same lines, it might be awesome if there were a dhr@ implementation of HDF5[1] using the same engineering methods, quality standards, and long-term maintenance guarantees as SQLite. Taking that idea further, if there were a data repository management system, like Fossil, but with the goals (or additional goals) of managing HDF5 based instrumentation data rather than (or addition to) text file revision history, that could be a big deal within the scientific communities. [1]: https://www.hdfgroup.org/hdf5/ Though an open standard, there is only a single implementation of HDF5 (and it is less than inspiring). ___ 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 on HN
On 10/10/2016 10:02 AM, Adam Jensen wrote: > Along the same lines, it might be awesome if there were a dhr@ s/dhr/drh-crew ___ 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 on HN
On 10/10/2016 01:49 PM, Richie Adler wrote: > *Nobody* has the > excuse that version control is costly or complicated anymore. As I sit here trying to untangle the [Permuted Index][1] of documents, I realize there is most definitely a cost; I am paying it now. And, unfortunately, none of this attention and effort is being harnessed. I could be flagging small problems - something like making notes in the margin while reading a book - a syntax error here, a grammatical problem there, something that needs clarification or rephrasing, etc. If the interface were designed to collect that data, I imagine the developers could make good use of it and the cost of learning to use the system would be reduced even further. [1]: http://www.fossil-scm.org/index.html/doc/trunk/www/permutedindex.html ___ 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] Pedagogy Think Tank or Documentation Framework RFC
Here's an idea that might be a little complicated to describe: Every time a [potential] user interacts with the documentation there is human attention, intelligence, and effort that is engaging the system. What if the system were designed to harness some of that? If a documentation framework included an interface that would enable users to provide feedback in a variety of ways (e.g., annotations, comments, ratings, etc.) that might be useful information. If a user is known, their feedback could be qualified or weighted in some way based on [expectations generated from] their history. If that analysis were automated and tied into the ticket system, developers and maintainers would only need to address fairly abstract alerts. Developer interaction with the ticket system could then provide feedback to the analysis system but I suspect I am probably way off the reservation at this point. Also, I suspect some kind of rules engine would need to be integrated, either embedded or as an extension. ___ 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] Pedagogy Think Tank or Documentation Framework RFC
On 10/11/2016 03:39 PM, jungle Boogie wrote: > I would call that a wiki, not only inside fossil-scm but in general. I am inclined to think that a wiki probably isn't sufficient for many projects. What I am casually proposing (just brainstorming, really) is a documentation framework that supports several different types of user (annotation) and developer (modification) involvement, all regulated by policy automation and human/system assessment, modeling and analysis. (Too much razzle-dazzle?) I started to sketch some diagrams earlier but ended up exploring [something like] enterprise architectures for various developer(s)/maintainer(s)/user(s) social organization. (See the work of [Max Weber][1] and [Karl Müller][2]). [1]: https://en.wikipedia.org/wiki/Tripartite_classification_of_authority [2]: https://en.wikipedia.org/wiki/Karl_H._M%C3%BCller Making the operations (policies, procedures, etc) of the system explicit, and the assessments and measurements quantifiable, all with significant automation support, once bootstrapped, a project could continue with little human involvement. If the documentation system includes pedagogical information and methods sufficient to train users to be maintainers and developers, such a project could endure the vicissitudes of interest. ___ 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] Pedagogy Think Tank or Documentation Framework RFC
On 10/11/2016 08:31 PM, Ron W wrote: > Sounds like something Google Docs does or could easily do (at least in > Google docs for Business). I'm not familiar with any recent incarnation of Google Docs. A quick glance at my white board and I see four loops of interaction with the documentation system: 1. Developers - creation 2. Maintainers - modification 3. Users - annotation 4. SRC/runtime - verification Each of those loops [in my current view] would involve data collection and analysis with hooks into the [policy automation][1] system and ticket system. [1]: https://www.youtube.com/watch?v=B9pulMZwUUY "Checklists For Better Software" Item 4 in that list is rich with possibilities; e.g., examples & demonstrations within the documentation could be executed and assessed, there could be meta-data within the documentation expressing various dependency relations to sections or areas of the source code, etc. ___ 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] Pedagogy Think Tank or Documentation Framework RFC
Concerning the actual contents of a documentation system, I suppose a framework might be composed of templates for: 1. Command syntax quick reference - fossil help ?cmd? 2. Command detailed reference 3. Cookbook-like containing "recipes" for various scenarios 4. Overview 4a. System introduction - purpose, requirements, various metrics 4b. Conventions, organization 5. Tutorials - user, maintainer, developer An item 2 template might be structured like this: > Relevant Definitions > Description > Example > Explanation > Rationale Where the Examples might be excerpts from various Cookbook recipes (with meta-data defining any dependency relations to source code and/or other parts of the documentation). Templates for the metrics of 4a could get interesting (possibly tying into a test suite and/or incorporating user statistics). The idea is to provide system engineers with relevant data and quantified decision points upfront. Item 5 is tricky. Would there need to be an underlying/intermediate knowledge-base or would it be sufficient to have direct dependency relations to the source? ___ 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] remote check in
On 10/23/2016 06:13 PM, Scott Doctor wrote: > > On 10/23/2016 13:59, Artur Shepilko wrote: >> It's not clear what type of project the OP is trying to setup, whether >> it's a programming-related project, or general document-repo type. >> > I am doing research where we may do a dozen iterations a day generating > about 10-100MB of files per iteration. within a short period of time we > will have well over a terabyte of information. My current workflow uses > a database (was filemaker but switched to sqlite a while ago) like a > library card catalog with notes and status fields. The files are a > combination of analysis code, text csv, binary, and documentation. > Occasionally we find something and want to go back to older data and > re-run the experiment with a few tweaks, or modify the analysis program. > I have information overload and finding stuff, even with it cataloged in > a database, is becoming a significant chore. So I am trying out > different techniques, such as using fossil, to track the experiments and > the large volume of information. Welcome to the party, Scott. https://youtu.be/lv0o9Lw3nz0?t=3m44s [My foray down that road](http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23837.html) ___ 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] remote check in
On 10/24/2016 01:33 PM, Scott Doctor wrote: [snip] > I think the documentation should group the most commonly used commands > from the master list. Maybe make several groups presented in most-used > to rarely-used groupings. A primer should avoid permuting the possible > operations until later (it just adds to the confusion) and focus on a > complete real example with the concepts explained as though the reader > is seeing it for the very first time. [snip] > The documentation needs a newbie primer that better explains how commits > and syncing works. I now mostly figured it out, but was initially > discouraged because of the seemingly (incorrect) concept of operation > for syncing with the main repository. > > A problem with most manuals for many software products is that an > assumption is made that the reader already understands the concept of > operation. If the reader is confuzzled at the start, then explanations > of the commands do not absorb without an understanding why it is being > done. Déjà vu http://www.mail-archive.com/search?l=fossil-users%40lists.fossil-scm.org&q=subject:%22\[fossil\-users\]+Pedagogy+Think+Tank+or+Documentation+Framework+RFC%22&o=newest But there isn't much of a feedback mechanism in the software engineering process to harness and utilize this information - it's still all done in a willy-nilly, back-channel, human-toil fashion. C'est la vie ___ 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] windows compiling with MS VC
On 10/24/2016 02:17 PM, Richard Hipp wrote: > Yes, except that Andy broken the build while we were in the quiet > period leading up to the 1.36 release Nice job, Andy http://big.assets.huffingtonpost.com/tumblr_nqxexloObr1rubttio1_400.gif ___ 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] remote check in
On 10/24/2016 03:07 PM, Warren Young wrote: > I don’t know that Fossil is all that close to any other software > system you’ve likely used before. Isn't it a file (version) management system based on an embedded database? On 10/23/2016 06:13 PM, Scott Doctor wrote: > My current workflow uses a database (was filemaker but switched to > sqlite a while ago) like a library card catalog with notes and status > fields. It sounds like you rolled your own file management system; the difference being that, with Fossil, the managed files are stored *in* the database. For a while I imagined it would be useful if the Fossil file management system were also capable of tracking and referencing files that are not stored in the database. But after thinking more about the requirements and use-cases, Fossil is probably in a funky territory of being too light-weight in its capabilities to be the solution, and too monolithic to be incorporated into a solution. It has however attracted/inspired several people from the research/experimentation arena (to the mailing list) who need a tool-suite that supports modern [science][1] with software engineering and data analysis methods. Again, I don't think Fossil is the solution to this open problem. [1]: By "science" I mean knowledge engineering informed by epistemological sophistication and a high traction with reality. ___ 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] remote check in
On 10/24/2016 04:59 PM, Warren Young wrote: > On Oct 24, 2016, at 2:32 PM, Adam Jensen wrote: >> Isn't it a file (version) management system based on an embedded database? > > Under casual inspection, Fossil presents itself to the user that way, but if > you dig into the way it actually works, you quickly find many places where > Fossil doesn’t behave like a POSIX filesystem. (Or an NTFS one, for that > matter.) [snip] By file management system (as opposed to a filesystem) I mean something more along the lines of managing the logistics, accounting, and presentation of files (rather than simply the storage of files). > There is an experimental (?) feature of Fossil allowing it to operate as a > FUSE filesystem. (fossil help fusefs) I suspect if you tried to use it that > way for any complex software build system — say, that of Firefox — that you’d > run into one or more of the above problems, or perhaps others I haven’t > cataloged, as the build system makes assumptions about POSIX semantics that > Fossil simply doesn’t provide. If a class of files were managed by Fossil that were not stored in the database but, rather, in the filesystem, it seems like FUSE might be a way to present various views (or checkouts) to a user. The current implementation seems to be a bit primitive and probably isn't usable for large binary files. http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23865.html ___ 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] git incremental import speedup.
On 10/26/2016 05:37 PM, Karel Gardas wrote: > I'm now able to import OpenBSD > source tree from OpenBSD src git mirror to fossil. This might be a silly question since I am terribly uniformed of the issues but could you have imported the OpenBSD source directly from their CVS repository? http://www.fossil-scm.org/index.html/wiki?name=Import+CVS+Repositories http://www.openbsd.org/anoncvs.html ___ 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 diff: extra empty lines in non-console output on Windows
On 10/31/2016 06:24 AM, Richard Hipp wrote: > On 10/31/16, Artur Shepilko wrote: >> I would've >> gladly fixed it myself, but have not mailed yet the Contributor Agreement.. >> (I have signed it though :) >> > > Please do mail in your CLA. And maybe also post a patch to this mailing list. > Would a GPG signed statement suffice? (It doesn't apply to me; I'm just generally curious). How attached to paper and scribbling is the legal system? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] OpenSSL in the source tree
When compiling on CentOS-7, 'configure --with-openssl=auto' doesn't find what is needed. How can OpenSSL or LibreSSL source be placed in the 'fossil/compat' directory such that 'configure --with-openssl=tree' will work? I've tried both: tar xzf openssl-1.1.0b.tar.gz -C ~/build/fossil/compat/ cd ~/build/fossil/compat/ mv openssl-1.1.0b openssl But that results in: --- Checking for ssl in source tree...no Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support --- Any ideas? ___ 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] OpenSSL in the source tree
On 11/02/2016 02:29 AM, Joe Mistachkin wrote: > I think using OpenSSL 1.1 will only work on the "openssl-1.1.0" branch. > > Here are the commands I generally use to get things all working in the > source tree: > > cd compat/zlib && ./configure && make > cd .. > wget -4 https://www.openssl.org/source/openssl-1.0.2j.tar.gz > tar -zxvf openssl-1.0.2j.tar.gz > mv openssl-1.0.2j openssl > cd openssl > ./config --with-zlib-include=../compat/zlib --with-zlib-lib=../compat/zlib > make depend > make > cd ../.. > ./configure --with-zlib=tree --with-openssl=tree > make Thanks, Joe! For posterity, I configure with additional options (and this works): cd ../../build ../configure --prefix=$HOME/.local --with-openssl=tree --with-zlib=tree --with-th1-docs --with-th1-hooks --with-tcl=$HOME/.local/lib --disable-fusefs --json ___ 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] OpenSSL in the source tree
On 11/02/2016 05:45 AM, Jan Nijtmans wrote: > 2016-11-02 7:29 GMT+01:00 Joe Mistachkin: >> I think using OpenSSL 1.1 will only work on the "openssl-1.1.0" branch. > > For Windows, that's true. For other platforms, openssl-1.1 works fine > in Fossil 1.36 or later. The reason is that dll names were changed in > openssl-1.1.0, this needs some build changes. But on other platforms, > openssl is 'almost' upwards compatible, at least sufficiently for > fossil to work unmodified. > >> Here are the commands I generally use to get things all working in the >> source tree: >> >> cd compat/zlib && ./configure && make >> cd .. >> wget -4 https://www.openssl.org/source/openssl-1.0.2j.tar.gz >> tar -zxvf openssl-1.0.2j.tar.gz >> mv openssl-1.0.2j openssl >> cd openssl >> ./config --with-zlib-include=../compat/zlib --with-zlib-lib=../compat/zlib >> make depend >> make >> cd ../.. >> ./configure --with-zlib=tree --with-openssl=tree >> make > > So, just use openssl-1.1 in the above, and everything should work fine. openssl-1.1.0b did not work today. It (openssl) compiles fine but configure (fossil) does not acknowledge its existence. Using the same procedure, openssl-1.0.2j is recognized during configure (fossil) and builds without errors. ___ 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] OpenSSL in the source tree
On 11/02/2016 06:33 AM, Martin Gagnon wrote:
> If you want to use openssl from your distro, you need to install the
> development package of openssl.
>
> I think it's "openssl-devel" on CentOS.
>
> I'm not very familiar with CentOS but if you do:
>
> $ yum install openssl-devel
>
> the configure script *should* find what it needs.
The platform's openssl packages are installed but the configure script
does not find them.
$ yum list installed | grep -i openssl | awk '{print $1}'
apr-util-openssl.x86_64
openssl.x86_64
openssl-devel.x86_64
openssl-libs.x86_64
pyOpenSSL.x86_64
xmlsec1-openssl.x86_64
xmlsec1-openssl-devel.x86_64
There is also a problem in building a static fossil on this platform
(CentOS-7).
$ ../configure --prefix=$HOME/.local --with-openssl=tree
--with-zlib=tree --with-th1-docs --with-th1-hooks
--with-tcl=$HOME/.local/lib --disable-fusefs --json --static
$ make
...
/usr/bin/ld: cannot find -ltcl8.6
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
I've tried (without success):
$ ../configure --prefix=$HOME/.local --with-openssl=tree
--with-zlib=tree --with-th1-docs --with-th1-hooks
--with-tcl=$HOME/.local/lib --disable-fusefs --json --static
LDFLAGS="-L/usr/lib64 -L${HOME}/.local/lib" CPPFLAGS="-I/usr/include
-I${HOME}/.local/include"
___
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] Error compiling FOSSIL trunk
On 11/02/2016 12:33 PM, Tony Papadimitriou wrote: > c:\fossil\win\winhttp.h(24) : error C2004: expected 'defined(id)' > c:\fossil\win\winhttp.h(24) : fatal error C1012: unmatched parenthesis : > missing ')' > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 12.0\VC\BIN\cl.EXE"' : return code '0x2' > Stop. I noticed that a checkout from about ten hours ago failed to build but a more recent checkout from about an hour ago builds without errors. (I don't know if it's trustworthy). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] submitting issue reports to/about fossil-scm.org
N00b here, I am reading the documentation on fossil-scm.org and as I [inevitably] find issues how should they be reported? (Hey, it's free proof-reading; might as well make use of it to improve the documents, right?) For example, http://fossil-scm.org/index.html/doc/trunk/www/webui.wiki within "Drop-Dead Simple Startup" the sentence: "Notice that Fossil automatically finds an unused TCP port to run the server own and automatically points your web browser to the correct URL." should probably say: "...run the server on and..." rather than "...run the server own and..." What is the best way to report little things like this? Also, what is a convenient format for project maintainers? (an HTML diff?) ___ 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] submitting issue reports to/about fossil-scm.org
On Tue, 21 Jul 2015 12:40:27 -0700 jungle Boogie wrote: > I'm not a maintainer but this is what I have done in the past, with > guidance of others. > > 0. clone the repo > 1. make your changes > 2. fossil changes to list your changes > 3. fossil diff filename > > here's the diff: > --- www/webui.wiki > +++ www/webui.wiki > @@ -61,11 +61,11 @@ >fossil ui > > The latter case is a very useful short-cut when you are working on a > Fossil project and you want to quickly do some work with the web interface. > Notice that Fossil automatically finds an unused TCP port to run the > -server own and automatically points your web browser to the correct > +server on and automatically points your web browser to the correct > URL. So there is never any fumbling around trying to find an open > port or to type arcane strings into your browser URL entry box. > The interface just pops right up, ready to run. > > The Fossil web interface is also very easy to setup and run on a Interesting, thanks! What is step 4? Is the diff submitted to this mailing list, or is some kind of repo sync performed, or is a ticket submitted through the https://fossil-scm.org/index.html/ticket web interface (I don't see a way to do that, which seems odd)? ___ 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
I sent a message last night before joining the mailing list (today) and I'm not certain if it (last night's post) was distributed to the list or not. It's not displayed in the list archive yet. Just in case, here it is: On 07/13/2016 06:18 PM, Adam Jensen wrote: > This might be a bit convoluted but is it possible to use fossil-scm as > an SQLite db with the schema/data under revision control? If this > functionality doesn't already exist in fossil, would it be difficult, > awkward, or crazy to try to implement it? > > It seems like such an obvious thing to do that I guess it either already > exists or it's so technically twisted that it's virtually impossible. > > If this functionality doesn't exist, how would you do it? After thinking a little more about this, it seems like maybe this isn't something that should be incorporated into Fossil [or SQLite] but rather this could be a third system that is based on the other two. To add a little more verbiage and description to the basic idea, what I am imagining is (I'm going to assume that in this new system a single db file can support multiple databases) an SQLite database with version control on the schema and data. This might be accomplished in a fashion similar to the original SCCS - every SQL command that causes changes to the [working copy] database is saved in the version history (a fossil-like database in this common db file). With this, any version of the database could be recreated by replaying the history. This process could be sped up by saving or creating snapshots of the database at various moments in its history (all in the common db file (and, perhaps, read-only)) and then a specific version can be created by replaying the relevant set of SQL changes made after the snapshot. (This description is just to get the idea across; there are probably more clever ways to implement it). Another aspect of this third system is the typical fossil-like data sharing. 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). For fun, and somewhat whimsically, a name for this Fossil/SQLite hybrid might be DVCSQLite . ___ 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
I'm a little puzzled by the lack of response - good, bad, ugly, be gone with you - anything will do. Is this kind of speculation taboo in this community or does it just take time to ponder the implications? Would the SQLite developer list be more appropriate/receptive? I'm very unfamiliar with these communities and I am concerned that I might have stumbled into some kind of faux pas here. On 07/14/2016 02:31 PM, Adam Jensen wrote: > I sent a message last night before joining the mailing list (today) and > I'm not certain if it (last night's post) was distributed to the list or > not. It's not displayed in the list archive yet. Just in case, here it is: > > On 07/13/2016 06:18 PM, Adam Jensen wrote: >> This might be a bit convoluted but is it possible to use fossil-scm as >> an SQLite db with the schema/data under revision control? If this >> functionality doesn't already exist in fossil, would it be difficult, >> awkward, or crazy to try to implement it? >> >> It seems like such an obvious thing to do that I guess it either already >> exists or it's so technically twisted that it's virtually impossible. >> >> If this functionality doesn't exist, how would you do it? > > After thinking a little more about this, it seems like maybe this isn't > something that should be incorporated into Fossil [or SQLite] but rather > this could be a third system that is based on the other two. > > To add a little more verbiage and description to the basic idea, what I > am imagining is (I'm going to assume that in this new system a single db > file can support multiple databases) an SQLite database with version > control on the schema and data. This might be accomplished in a fashion > similar to the original SCCS - every SQL command that causes changes to > the [working copy] database is saved in the version history (a > fossil-like database in this common db file). With this, any version of > the database could be recreated by replaying the history. This process > could be sped up by saving or creating snapshots of the database at > various moments in its history (all in the common db file (and, perhaps, > read-only)) and then a specific version can be created by replaying the > relevant set of SQL changes made after the snapshot. (This description > is just to get the idea across; there are probably more clever ways to > implement it). > > Another aspect of this third system is the typical fossil-like data > sharing. 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). > > For fun, and somewhat whimsically, a name for this Fossil/SQLite hybrid > might be DVCSQLite . > > ___ > 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-scm as an SQLite db with schema/data revision control
On 07/23/2016 03:37 PM, Richard Hipp wrote: > On 7/23/16, Adam Jensen wrote: >> I'm a little puzzled by the lack of response > > Lots of people on vacation. Not much activity on *any* project during > the summer months > I'm beginning to suspect that I might have proposed something based in such compounded ignorance that there's no simple way for anyone to explain the problems of it to me... which is totally cool, I'm somewhat out of my areas of competence here. ___ 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
On 07/24/2016 03:49 AM, Eduardo Morras wrote: > > You can use the Sqlite session extension to produce patch files between > db file versions. It has some restrictions on schema and documentation > is scarce, but if I had the same goal as you, I'll try that way. > > To use it you need Sqlite version >= 3.13.0 > > www.sqlite.org/sessionintro.html > That's really nifty - the base tech seems to already exist. I wonder how much engineering effort would be required to gut, configure, and extend the existing SQLite/Fossil tech into a distributed, version controlled database management system? ___ 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
On 07/23/2016 07:05 PM, Ron W wrote: > Hello, > > What you are thinking is not impossible. > Thanks for the confirmation, I've been speculating about novel system architectures and unusual use-cases without sufficient fundamental knowledge and experience - that makes for dangerous propositions and a very delicate position. Thanks again, for the sanity check. > You do need to be aware that Fossil only uses SQLite as an index engine. > Fossil does not synchronize the actual databases, only the "artifacts" > (stored as "blobs" in the database). Aside from the blob table, the > tables in the database are derived from the information in the artifacts. > > When information in a Fossil repository is added or updated, Fossil > creates new artifacts to contain the new or update information, stores > those in the blob table, then updates the various other tables. > We're probably on the same page here. I've recently opened a fossil repository file with the sqlite3 application and explored the schema (superficially). > When Fossil pushes to or pulls from another repository, only blobs are > transferred. The receiving Fossil adds those to it's blob table, then > updates the other tables as needed. > I think I get the gist of what you are saying. At some point it would probably be worthwhile [for me] to explore the communication protocol. > Fossil could be used to synchronize 2 or more SQLite databases. Schema > updates could be handled as tickets, the body of each ticket containing > the SQL commands required to make the schema changes. For new clones of > the database, a serialized version of the schema could be used, rather > than "replaying" the schema tickets. Synchronizing tables would require > serializing their content into artifacts, which Could then be > pushed/pulled normally by Fossil. > > The serialization of the schema and the table contents would have to be > done by an external application. Maybe libfossil could help with that. > Otherwise, each new artifact could be created in to a file, then the > files committed into Fossil using system() calls to invoke Fossil's > command interface. Alternately, the artifacts could be added as wiki > pages via Fossil's HTTP interface (which would avoid launching the > Fossil application multiple times, though the push/pull would still have > to be done via the command interface). > That might be an interesting approach to putting together a prototype demonstration-of-concept system, just using standard Fossil and SQLite and some scripting. [The Session Extension](http://www.sqlite.org/sessionintro.html) pointed out by Eduardo seems to have a lot of potential. "The session extension provides a mechanism for recording changes to some or all of the rowid tables in an SQLite database, and packaging those changes into a "changeset" or "patchset" file that can later be used to apply the same set of changes to another database with the same schema and compatible starting data. A "changeset" may also be inverted and used to "undo" a session." Wow, whoever designed that extension had Vision. Given this capability, would you still use Fossil tickets to record, manage, and communicate the changesets or do you suppose the changesets (or some variation) might somehow be stored in the blob table? ___ 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
On 07/25/2016 04:38 AM, Carlo Miron wrote: > See also [rqlite] (https://github.com/rqlite/rqlite). > Hey, sweet! That might be slick for situations where three to nine SQLite databases need to be continuously synchronized through automated consensus. That scenario is quite a bit different from DVCS on a database, but it's nifty nonetheless. Thanks for the reference, I'm tinkering with rqlite now :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
