Re: [fossil-users] About to merge the forum-v2 branch

[Thomas Levine]

Also, despite the inconvenience of using a web browser, I anticipate that this 
feature will be very helpful for me.
___
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] Backups of deconstructed fossil repositories

[Thomas Levine]

On Sun, Jun 17, 2018, at 20:05, Warren Young wrote:
> However, I’ll also give a counterargument to the whole idea: you 
> probably aren’t saving anything in the end.  An intelligent deconstruct 
> + backup probably saves no net I/O over just re-copying the Fossil repo 
> DB to the destination unless the destination is *much* slower than the 
> machine being backed up.
> 
> (rsync was created for the common case where networks are much slower 
> than the computers they connect.  rsync within a single computer is 
> generally no faster than cp -r, and sometimes slower, unless you take 
> the mtime optimization mentioned above.)
> 
> The VM/ZFS + snapshots case has a similar argument against it: if you’re 
> using snapshots to back up a Fossil repo, deconstruction isn’t helpful.  
> The snapshot/CoW mechanism will only clone the changed disk blocks in 
> the repo.
> 
> So, what problem are you solving?  If it isn’t the slow-networks 
> problem, I suspect you’ve got an instance of the premature optimization 
> problem here.  If you go ahead and implement it, measure before 
> committing the change, and if you measure a meaningful difference, 
> document the conditions to help guide expectations.

I want my approximately daily backups to be small.

I currently version the fossil SQLite files in borg, and I am considering 
versioning instead the artefact dumps. I figure these will change less than the 
SQLite files do and that they also will be smaller because they lack caches.

But the backups are already very small.

I suppose I could test this.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Backups of deconstructed fossil repositories

[Thomas Levine]

As content is added to a fossil repository, files in the corresponding
deconstructed repository never change; they are only added. Most backup
software will track changes to the deconstructed repository with great
efficiency.

I should thus take my backups of the deconstructed repositories, yes?
That is, should I back up the SQLite database format of the fossil
repository or the deconstructed directory format of the repository?

One inconvenience I noted is that the deconstruct command always writes
artefacts to the filesystem, even if a file of the appropriate name and
size and contents already exists. Would the developers welcome a flag
to blob_write_to_file in src/blob.c to skip the writing of a new
artefact file if the file already exists? That is, rebuild_step in
src/rebuild.c would check for the existance of the file corresponding
the artefact's hash, and if such a file exists already (even if its
content is wrong), rebuild_step would skip writing this artefact.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Documentation requests

[Thomas Levine]

In the discussion of "Setting up an internet Fossil server",
Richard Hipp wrote:
> There is no step-by-step guide right now, but it would be great if you
> could write one up and contribute it!

I happen to like writing documentation. Are there other particular things
that are requested often but not well documented? Because I might write
the documentation.

In the case of the fossil web server setup, for example, I envision
an almost patronizing tutorial on alternative web server configuration
options, the concept of proxy servers, installation of packages in
various operating systems or web hosts, and how to debug web server
configurations.
___
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] Setting up an internet Fossil server

[Thomas Levine]

Since it seems that the only dynamic stuff is in PHP and fossil,
I suggest using Apache mod_php and mod_cgi (contrary to Warren's
suggestion), as I think the configuration will be easier.

If that is an option, you can copy my configuration. I have a file in my
web root called "scm" that says this:

  #!/usr/bin/env fossil
  directory: /home/protected/r
  repolist

That file is marked as a CGI script, as in this template that generates
the htaccess file.
https://thomaslevine.com/scm/dadaportal/artifact?ln=6..8=ddbddcaaac7287d8

The repositories are in /home/protected/r.

It corresponds to this web page.
https://thomaslevine.com/scm

You would of course have to switch the rest of your configuration to
Apache, but that might be very easy.
___
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] Rebrand Fossil as "Blockchain-VCS"...

[Thomas Levine]

The other distributed version control systems are all blockchains too,
yes?

I find the term "distributed ledger" more interesting, as I store the
accounts for my unincorporated server cooperative in GNU ledger format,
controlled redundantly in git (for my colleagues) and fossil (for me).

This distributed ledger is private, 2.4mb in size (including many other
files, such as copies of invoices), and portable. If my colleagues would
use fossil instead of git, the history would be immutable. I appreciate
the possibility to store far more complex information than is convenient
in Bitcoin, but if I were to restrict the information to what is stored
in Bitcoin, I could represent a transaction history in something like
one-tenth the space that it would take up in Bitcoin.

Fossil is far superior to Bitcoin for situations where you can weakly
trust the other people who are editing your ledger.
___
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] Trolling GitHub for ideas

[Thomas Levine]

The main GitHub feature that I would like is directions as to how to
download and check out the repository. I like to implement this in
fossil as a footer.
https://thomaslevine.com/scm/langrompiloj/

I believe that someone mentioned this feature in the Fossil-NG Bloat
thread, but I can't find the message at the moment.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] [Nmh-workers] Merging Source Files with git. (fwd)

[Thomas Levine]

Ralph asks whether a particular feature is available in git,
so I am curious, is it available in fossil?

--- Forwarded Message

Date:Fri, 10 Nov 2017 23:51:07 +
From:Ralph Corderoy 
To:  nmh-work...@nongnu.org
Subject: [Nmh-workers] Merging Source Files with git.

Hi,

I'm in the Augean process of creating .h interface files for each of the
.c implementation files, depleting h/prototypes.h of content along the
way, to help show the dependencies between the modules.  Something
that's obvious before and during is there's too many one-function C
files, often with a piddly little functions, and a whole clutch of them
are related.

This suggests foo_{add,del,find,save,tweak}.c should in time become
foo.c, allowing globals to become statics in foo.c, and currently global
structs, etc., to also move to foo.c.  Is there a good way of doing
this, in multiple stages if necessary, that allows git to preserve the
chain of history?  Say telling it foo_add.c is now foo.c in one commit,
and then foo_del.c has merged with foo.c in the next.

- -- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

- -- 
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[fossil-users] Documentation on how to clone and how to download a tarball

[Thomas Levine]

People often don't know how to clone or download a tarball from my
fossil server, so I wind up documenting it in the homepage of each
particular project. Is there a more convenient way of providing this
documentation, such as generic documentation page on this topic and a
skin that links to this documentation?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Removing dangling links to checkouts

[Thomas Levine]

Suppose that some of a repository's checkout references are no longer
valid.

$ fossil version
This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC
$ sqlite3 horetu.fossil "select * from config where name like 'ckout%';"
ckout:/directory/does/not/exist/anymore/|1|1463006565
ckout:/home/tlevine/horetu/|1|1475658284

The question: Is there a good way to remove the dead ones? I have
already reviewed them to determine that it is safe to remove them.

This may also be against the fossil spirit; it may be more coherent to
expect users to check whether each checkout is indeed still a checkout
before doing anything with the directory.

In my case, it turned out that there was a better way that did not
require access to the checkouts. In an earlier version of my
implementation of the missing "fossil all configuration push" in sh, I
ran "cd" on the checkout directory and then ran "fossil config push"
from there. This produced errors on missing directories, leading me to
wonder how to remove them.
http://src.thomaslevine.com/rc/info/e1c590fa8f233a554caab90b932a356456d7b9e4?txt=1=14

But I have since fixed my "fossil-all-configuration-push" to use -R.
http://src.thomaslevine.com/rc/artifact/f6fad8431281ad7d
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Correction of errors in the documentation of the -R flag to the push and sync commands

[Thomas Levine]

Before this check-in, the documentation incorrectly repeats -R flag
documentation for the "pull" command in the -R flag documentation for
the "push" and "sync" commands. This change adds accurate documentation
for the "push" and "sync" commands. Additionally, I explicitly state in
all three documentation lines that the -R flag corresponds to the local
repository, as I think this makes it easier to understand what the flag
does. The local versus remote distinction is already established at the
beginning of the documentation for each of these commands.
http://src.thomaslevine.com/fossil/ci/ddf566bceb203948?sbs=1
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Push to multiple remote urls at once

[Thomas Levine]

Hi,

I want to keep two remote backups of my repository. Can I configure
fossil to push to multiple URLs on "push"?  Or, is there a better way to
make redundant backups of fossil repositories?

Tom
___
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] Noob usage questions

[Thomas Levine]

On 22 Apr 15:38, Steve Schow wrote:
> 3 - whether to use auto-sync or not.

I think you are making things overly complicated in question 3.
If I understand properly, you want one trusted person to approve code
before it gets into trunk on the main repository. Here is a policy that
could accomplish that.

Everyone works on separate repositories. When someone wants to
put something in the main repository, he or she contacts the person who
can write to the main repository, noting the branch, tag, or checkin.
When that person approves of a change, he or she pulls from the
appropriate repository and pushes to the main repository. The contact
could occur inside tickets in the main repository, if you like.
This is, in fact, the exact same workflow I would use with git.

I don't see the connection to auto-sync.

It is quite difficult it is to delete information from a fossil
repository, so I don't think you have to trust your developers as much
as you would with a git repository. Because of that, you might be able
to come up with a less cumbersome workflow, such as the one that Richard
alluded to.



I'm not very good at fossil yet either, so I don't have thoughts on
the other questions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] CGI arguments other than "repository" and "notfound"

[Thomas Levine]

Hi,

"fossil serve" provides several options that I can't find for
the CGI program "fossil cgi".

The only "cgi" options I have managed to find are "repository" and
"notfound", as documented here.
https://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki

I want to use --repolist and --baseurl in the CGI program.
Is this possible?

Here are the "serve" options, for reference.

  > fossil help serve | sed -n '/Options/,$ p'
  Options:
--baseurl URL   Use URL as the base (useful for reverse proxies)
--createCreate a new REPOSITORY if it does not already exist
--files GLOBLISTComma-separated list of glob patterns for static files
--localauth enable automatic login for requests from localhost
--localhost listen on 127.0.0.1 only (always true for "ui")
--nojailDrop root privileges but do not enter the chroot jail
--notfound URL  Redirect
-P|--port TCPPORT   listen to request on port TCPPORT
--th-trace  trace TH1 execution (for debugging purposes)
--repolist  If REPOSITORY is dir, URL "/" lists repos.
--scgi  Accept SCGI rather than HTTP
--skin LABELUse override skin LABEL

  See also: cgi, http, winsrv

Thanks

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