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

[Karel Gardas]

Hello,

I've tried the trick with marking explicitly parent of incrementally
imported changes line, but this does not work fully. First of all, it
definitely helps with the timeline, I can see both or all independent
lines of incremental imports nicely connected together. I can also see
just one resulting leaf, but on update of checkout from such
repository fossil fails and removes all files which were not touched
by the last incremental import line.

I'm attaching tarball of 3 scripts which clearly shows the behavior
and may be used to duplicate/debug it. Put it into some directory and
run ./test.sh -- also please modify reconnect.sh first and if your GNU
grep is "grep" then please rename "ggrep" to "grep". The scripts were
developed on my Solaris workstation where GNU grep is ggrep.

Thanks!
Karel

On Sat, Sep 3, 2016 at 8:26 PM, Karel Gardas  wrote:
> On Fri, Sep 2, 2016 at 8:28 PM, Svyatoslav Mishyn  
> wrote:
>> Maybe `fossil reparent` and then `fossil leaves --recompute` will help..
>>
>
> Great! This is indeed working as long as there is acceptable to have
> additional artifacts -- are those tags? My testing timeline shows
> this:
>
> $ fossil timeline
> === 2016-09-03 ===
> 17:06:00 [4250222b71] Edit [36f4b3ef8d4a245d|36f4b3ef8d]: Add "parent"
> with value "71ffe7ef09c0c3d6e05cd6d31b43e2850586323c". (user: karel)
> 17:05:12 [533d224a5c] *CURRENT* change 15 (user:
> karel.gar...@centrum.cz tags: trunk)
> 17:05:11 [5be7e9c3a3] change 14 (user: karel.gar...@centrum.cz tags: trunk)
> 17:05:09 [9ffa7c82c9] change 13 (user: karel.gar...@centrum.cz tags: trunk)
> 17:05:08 [1f98a7fe09] change 12 (user: karel.gar...@centrum.cz tags: trunk)
> 17:05:07 [36f4b3ef8d] change 11 (user: karel.gar...@centrum.cz tags: trunk)
> 17:04:08 [fb6393d303] Edit [6abd71f3a3f2dba4|6abd71f3a3]: Add "parent"
> with value "2c3bd124e4733718b448835fe9a8767b0bce9067". (user: karel)
> 14:30:14 [71ffe7ef09] change 10 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:13 [d8a49f0142] change 9 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:12 [e17627bb9e] change 8 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:11 [5d3ddbd363] change 7 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:10 [6abd71f3a3] change 6 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:09 [2c3bd124e4] change 5 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:08 [a139dda296] change 4 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:07 [da50998d5f] change 3 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:06 [7f46e6e37d] change 2 (user: karel.gar...@centrum.cz tags: trunk)
> 14:30:05 [acfb6b6234] change 1 (user: karel.gar...@centrum.cz tags: trunk)
> +++ no more data (17) +++
>
>
> The question is if the process may be somehow automated or even part
> of incremental git import? I'm asking since usually the situation
> looks as:
>
> karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$
> fossil timeline
> === 2016-09-03 ===
> 18:15:39 [30a3929a48] change 10 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:38 [db0ddbb9ba] change 9 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:37 [aa40441d2d] change 8 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:36 [302c071b45] change 7 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:35 [2b36d21f54] change 6 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:33 [8a8dfe4da6] *CURRENT* change 5 (user:
> karel.gar...@centrum.cz tags: trunk)
> 18:15:32 [7848d4ba85] change 4 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:31 [ca027158d7] change 3 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:30 [92626573e1] change 2 (user: karel.gar...@centrum.cz tags: trunk)
> 18:15:29 [bac45c9453] change 1 (user: karel.gar...@centrum.cz tags: trunk)
> +++ no more data (10) +++
> karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$
> fossil leaves
>(1) 2016-09-03 18:15:39 [30a3929a48] change 10 (user:
> karel.gar...@centrum.cz tags: trunk)
>(2) 2016-09-03 18:15:33 [8a8dfe4da6] change 5 (user:
> karel.gar...@centrum.cz tags: trunk)
>
>
>
> this is after one import git -> fossil and after additional
> incremental import git -> fossil. Now I would need to connect
> 8a8dfe4da6 and 2b36d21f54 together by:
>
> karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$
> fossil reparent 2b36d21f54 8a8dfe4da6
> karel@silence:~/tmp/fossil-test/git-incremental-import/workspace-fossil$
> fossil leaves --recompute
>
> and after that I'm able to fossil update and be on the same tree like
> in git. However such approach is not too comfortable for running
> something like git to fossil mirror on OpenBSD's src repository in
> automatic manner since this requires user intervention of finding
> changes which need to be reconnected. I can probably write some script
> or simple program which would parse fossil timeline output and do
> that, but the question is if there is more easier way how to find
> "root" revision 

[fossil-users] 3rd Call For Papers - 23rd Annual Tcl/Tk Conference (Tcl'2016)

[akupries]

Hello Fossil Users, fyi ...

23rd Annual Tcl/Tk Conference (Tcl'2016)
http://www.tcl.tk/community/tcl2016/

November 14 - 18, 2016
Crowne Plaza Houston River Oaks
2712 Southwest Freeway, 77098
Houston, Texas, USA

[[ 7...6...5...4...3...2...1...
   Attention! One week to the paper deadline
]]
[[ Attention! Registration is open! Please have a look at
   http://www.tcl.tk/community/tcl2016/register.html
]]

[[ Known Speakers
-- Tutorials

  * Clif Flynt - GUI Testing with tktest
 Introduction to Tcl 1
 Introduction to Tcl 2
 Tcl on Android

  * Joe Mistachkin - Advanced Windows Integration with Eagle, Garuda, and Harpy

  * Sean Woods - Advanced TclOO & Megawidgets in TclOO
 Building Tcl Extensions
 Fun with CoRoutines

]]

Important Dates:

Abstracts and proposals due   September 12, 2016
Notification to authors   September 19, 2016
WIP and BOF reservations open August 22, 2016
Hotel Room ReleaseOctober 22, 2016
Author materials due  October 24, 2016
Tutorials Start   November 14, 2016
Conference starts November 16, 2016

Email Contact:tclconfere...@googlegroups.com

Submission of Summaries

Tcl/Tk 2016 will be held in Houston, Texas, USA from November 14, 2016 to 
November 18, 2016.

The program committee is asking for papers and presentation proposals
from anyone using or developing with Tcl/Tk (and extensions). Past
conferences have seen submissions covering a wide variety of topics
including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Note:
We are especially interested in papers for OS X this time, to
complement the keynote.

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to tclconfere...@googlegroups.com no later than September 12, 2016. Authors of 
accepted
abstracts will have until October 24, 2016 to submit their final
paper for the inclusion in the conference proceedings. The proceedings
will be made available on digital media, so extra materials such as
presentation slides, code examples, code for extensions etc. are
encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 30 minutes to present their paper at
the conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 22, 2016. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in August 22, 2016. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the 

Re: [fossil-users] Unversioned files.

[Gour]

On Fri, 2 Sep 2016 13:05:43 -0400
Richard Hipp  wrote:

> At the moment, unversioned files are not part of the check-out.  So
> this is a feature.

OK. Thank you.

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?


Sincerely,
Gour

-- 
It is far better to discharge one's prescribed duties, even though
faultily, than another's duties perfectly. Destruction in the course
of performing one's own duty is better than engaging in another's
duties, for to follow another's path is dangerous.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users