Re: [fossil-users] Error compiling FOSSIL trunk

[Adam Jensen]

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

Re: [fossil-users] OpenSSL in the source tree

[Adam Jensen]

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] OpenSSL in the source tree

[Adam Jensen]

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

[Adam Jensen]

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

[fossil-users] OpenSSL in the source tree

[Adam Jensen]

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] fossil diff: extra empty lines in non-console output on Windows

[Adam Jensen]

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

Re: [fossil-users] git incremental import speedup.

[Adam Jensen]

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] remote check in

[Adam Jensen]

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] windows compiling with MS VC

[Adam Jensen]

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

[Adam Jensen]

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=subject:%22\[fossil\-users\]+Pedagogy+Think+Tank+or+Documentation+Framework+RFC%22=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] remote check in

[Adam Jensen]

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] Pedagogy Think Tank or Documentation Framework RFC

[Adam Jensen]

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] Pedagogy Think Tank or Documentation Framework RFC

[Adam Jensen]

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

[Adam Jensen]

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

[Adam Jensen]

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] Fossil on HN

[Adam Jensen]

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] Fossil on HN

[Adam Jensen]

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

[Adam Jensen]

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

[Adam Jensen]

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

[fossil-users] Pedagogy Think Tank or Documentation Framework RFC

[Adam Jensen]

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] Cutting fossil repository

[Adam Jensen]

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

Re: [fossil-users] Cutting fossil repository

[Adam Jensen]

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

[fossil-users] TH1 and/or Tcl

[Adam Jensen]

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] Incremental import breaks repo.

[Adam Jensen]

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

Re: [fossil-users] Unversioned files.

[Adam Jensen]

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] Unversioned files.

[Adam Jensen]

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.

[Adam Jensen]

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.

[Adam Jensen]

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.

[Adam Jensen]

On 09/11/2016 01:54 PM, Stephan Beal wrote:
> On Sep 11, 2016 18:18, "Adam Jensen" <han...@riseup.net
> <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.

[Adam Jensen]

On 09/11/2016 05:41 AM, Stephan Beal wrote:
> On Sep 10, 2016 19:31, "Adam Jensen" <han...@riseup.net
> <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

[fossil-users] fusefs issues

[Adam Jensen]

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.

[Adam Jensen]

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

Re: [fossil-users] Unversioned files.

[Adam Jensen]

On 09/09/2016 10:20 PM, Richard Hipp wrote:
> On 9/9/16, Adam Jensen <han...@riseup.net> 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.

[Adam Jensen]

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.

[Adam Jensen]

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.

[Adam Jensen]

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.

[Adam Jensen]

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] basic usage question - empty directories

[Adam Jensen]

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] basic usage question - empty directories

[Adam Jensen]

On 08/02/2016 10:57 AM, Ron W wrote:
> On Tue, Aug 2, 2016 at 12:26 AM, Adam Jensen <han...@riseup.net
> <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] How to host fossil repositories on web server that supports only FastCGI interface?

[Adam Jensen]

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

[Adam Jensen]

On 08/01/2016 11:01 PM, Ron W wrote:
> On Mon, Aug 1, 2016 at 8:22 PM, Adam Jensen <han...@riseup.net
> 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] basic usage question - empty directories

[Adam Jensen]

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

[Adam Jensen]

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

[Adam Jensen]

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

[fossil-users] basic usage question - empty directories

[Adam Jensen]

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

[Adam Jensen]

On 07/27/2016 10:37 AM, Ron W wrote:
> On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen <han...@riseup.net
> <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

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

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

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

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

[Adam Jensen]

On 07/23/2016 03:37 PM, Richard Hipp wrote:
> On 7/23/16, Adam Jensen <han...@riseup.net> 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

[Adam Jensen]

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

[Adam Jensen]

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] submitting issue reports to/about fossil-scm.org

[Adam Jensen]

On Tue, 21 Jul 2015 12:40:27 -0700
jungle Boogie jungleboog...@gmail.com 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 @@
bfossil ui/b
 
  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