Richard Hipp:
> I think this problem has been addressed in a more general way
> on the latest trunk. Please let me know if you find otherwise.
This works fine (tested only on Windows, so far), thank you very much!
--Florian
___
fossil-users mailing
On 7/21/18, Florian Balmer wrote:
>
> The current tip version of Fossil still
> exhibits the behavior summarized here:
>
> https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27269.html
>
I think this problem has been addressed in a more general way on the
latest trunk. Please let
> There's been some changes to fossil_exit() in the meantime, I'll check
> these, and report back here.
I was wrong, the changes were to fossil_fatal() and fossil_panic(),
and not to fossil_exit(). The current tip version of Fossil still
exhibits the behavior summarized here:
Warren Young:
> Quantify “a lot.”
I have some rarely committed-to but frequently web-accessed
repositories (with login), and I see daily backups of the modified
repository database, even though I'm sure I haven't committed
anything. It's like "hey, what's going on there with my babies?"
On 7/20/18, John P. Rouillard wrote:
> Does a clone/sync grab passwords and user accounts as well? I thought those
> weren't copied in the clone but were private to the repository.
If you have Admin or Setup privilege, you can do "fossil config sync user"
--
D. Richard Hipp
d...@sqlite.org
On Jul 20, 2018, at 3:32 PM, John P. Rouillard wrote:
>
> Does a clone/sync grab passwords and user accounts as well? I thought those
> weren't copied in the clone but were private to the repository.
You get a copy of the users table *if* you clone while logged in with a user
with Setup
Hi all:
In message
,
Florian Balmer writes:
>Richard Hipp:
>> ... create your backups by cloning and syncing ...
>
>Thank you for your comments.
>
>I see, this completely makes sense.
>
>The process of "restoring" a repository from backup would include
>copying database files, as syncing from
On Jul 20, 2018, at 5:04 AM, Richard Hipp wrote:
>
> create your backups by cloning and syncing
…with Admin privileges. Otherwise, you won’t get important things like the
user table. After the first clone, each backup should consist of both a
“fossil sync” as well as a “fossil conf pull
On Jul 20, 2018, at 2:12 AM, Florian Balmer wrote:
>
> There's a lot of backup traffic
Quantify “a lot.”
Do you have benchmark numbers showing that the current load is too high, and
that your wished-for changes will reduce load to acceptable levels?
> (This was also the main reason for my
Just one more thought:
Copying database files (vs. cloning) also includes any hand-made meta
changes, for example I remember adjusting the page size and journal
mode for older repositories, when the defaults for new Fossil
repositories were changed.
Of course `fossil rebuild --wal' after the
Richard Hipp:
> ... create your backups by cloning and syncing ...
Thank you for your comments.
I see, this completely makes sense.
The process of "restoring" a repository from backup would include
copying database files, as syncing from backup → original might not
work if something's gone
On 7/20/18, Florian Balmer wrote:
> But what is a good
> strategy to minimize backup traffic, if repository databases change
> that often?
>
Don't backup by copying the database file (which is not safe to do
anyhow, unless you shutdown Fossil during the copy, because otherwise
the database file
Stephan Beal:
> .. i'm not sure that i like it enough to justify the idea of
> maintaining two files where one file is sufficient.
The current implementation uses one single cookie database shared for
all repositories in the same directory, which can be excluded from
backups, and deleted (or,
On Fri, Jul 20, 2018 at 10:13 AM Florian Balmer
wrote:
> I have created a (surprisingly simple) patch to attach a separate
> login cookie database (shared among all repositories in the same
> directory), so that plain login and logout actions will no longer
> cause repository database writes.
As much as I like the simplicity of keeping the full repository
history in one single SQLite database, I see a minor downside.
There's a lot of backup traffic, if "non-contents changes" (such as
the admin and user logs, the login cookies, but also the "PRAGMA
optimize" information) are causing
15 matches
Mail list logo
