Re: [fossil-users] Amendments don't always survive rebuilds
On 6/11/18, Martin Gagnon wrote: > On Mon, Jun 11, 2018 at 02:24:48PM -0400, Richard Hipp wrote: >> Download does not work. > If it can help, The download works for me, but the repo are compressed > with xz (without the the ".xz" extension). Thanks. With that hint, I was able to repro the problem and check-in a fix. -- D. Richard Hipp d...@sqlite.org ___ 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] Amendments don't always survive rebuilds
On Mon, Jun 11, 2018 at 02:24:48PM -0400, Richard Hipp wrote: > On 6/9/18, Andy Goth wrote: > > Some amendments don't consistently survive rebuilds and syncs. I've > > noticed this with date changes and reparenting. Possibly it affects > > other types of amendments as well, but those are the two I've spotted. > > > > This has been plaguing me for years, but finally I have a repeatable > > test case. > > > > Repository before rebuild: > > https://drive.google.com/open?id=1-Ahs91NVigBX7uMk88wIBjClQj1yxGnm > > Download does not work. If it can help, The download works for me, but the repo are compressed with xz (without the the ".xz" extension). So, before to be able to use it, you have to rename from the files from .fossil to .fossil.xz. Then xz -d .fossil.xz. > There were errors coming from your script such that the "f amend" > commands were failing. > For the script, there's a few line warp in the email that cause the error. Per example, the newline between the "05" and the "24" on the following line: id=1; for day in 15 13 16 12 17 11 18 10 19 09 20 08 21 07 22 06 23 05 24 04 25 03 26 02 27 01; do f commit -f -m "$id" -tag "$id" Here's my re-indented version of the script that should works (if the email client doesn't break it) --%<-- #!/bin/bash fossil new test.fossil -admin-user username -date-override 2018-05-31 mkdir test cd test fossil open ../test.fossil fossil user default username id=1 for day in 15 13 16 12 17 11 18 10 19 09 20 08 21 07 22 06 23 05 \ 24 04 25 03 26 02 27 01; do fossil commit -f -m "$id" -tag "$id" -date-override "2018-06-$day" ((++id)) done for id in $(seq 1 26); do fossil amend -date "$(printf 2018-06-%02d "$id")" "$id" done --%<-- Regards, -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Hydra registrations open (open beta)
Hi all, I have opened registration on Hydra. Feel free to try it out at [ https://hydra.ecd.space/ ], and give me your feedback. Features: - Single sign-on; same username on all repositories. - Extra security features - Separate subdomains to limit cross-repository XSS attacks. - Each Fossil process runs in a chroot, with unique UID/GID. Best, Eduard ___ 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] Amendments don't always survive rebuilds
On 6/9/18, Andy Goth wrote: > Some amendments don't consistently survive rebuilds and syncs. I've > noticed this with date changes and reparenting. Possibly it affects > other types of amendments as well, but those are the two I've spotted. > > This has been plaguing me for years, but finally I have a repeatable > test case. > > Repository before rebuild: > https://drive.google.com/open?id=1-Ahs91NVigBX7uMk88wIBjClQj1yxGnm Download does not work. There were errors coming from your script such that the "f amend" commands were failing. Do you have any other ways for me to repro the problem? -- D. Richard Hipp d...@sqlite.org ___ 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] Amendments don't always survive rebuilds
On 6/9/18, Andy Goth wrote: > > This has been plaguing me for years, What is it that you are doing differently that is causing these kinds of problem? -- D. Richard Hipp d...@sqlite.org ___ 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 binary file size on FreeBSD (amd64)
Stephan Beal: > Try stripping the debug symbols: > strip fossil Thank you for the useful tip, now down to 3.6 MB! My MSVC/WinSDK toolset doesn't provide the equivalent utilities any more, as everything is controlled by compiler and linker flags -- and obviously for a longer time than my long-term memory span :) --Florian ___ 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 binary file size on FreeBSD (amd64)
Try stripping the debug symbols: strip fossil - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Mon, Jun 11, 2018, 07:55 Florian Balmer wrote: > When building Fossil on a recent out-of-the-box FreeBSD (amd64) > virtual machine, the resulting binary file is about 10.1 MB. The > binary files downloaded form [0] are at most 3.8 MB. > > [0] http://pkg.freebsd.org/ > > I have tried various ./configure options, FOSSIL_DYNAMIC_BUILD is > enabled (=1), and TCL seems to be disabled by default (or, is it?). > > Not that it matters (these times are over), but out of curiosity, why > is there such a difference? > > --Florian > ___ > 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] HTTP caching, again
Though I'm aware that this is not something you may consider useful
for Fossil, I'm posting a minor update, for the sake of correctness:
(0) Wrong Statement
Me:
> I think that "Vary: Cookie" is intended to work with unconditional
> HTTP requests: the browser is directed to stick to the expiry date
> and use the cached page, unless the cookies have changed.
I'm sorry I was wrong here.
"Vary: Cookie" directs clients to include cookies as part of their
"cache key", and it also works with conditional HTTP requests.
But if clients mark resources as stale due to cookie updates, they
will still "revalidate" them with conditional If-None-Match requests,
using their last-received ETag. And if the server does not consult all
the information from the cookies to generate its ETag (here, the user
login time), it won't produce a new ETag and expire the page, but
instead reply with "304 Not Modified".
(1) Introduced two Bugs
With the previous version of the patch, accessing the /uv page with no
file name specified caused an assertion failure, as doc_page()
repeatedly tries various index documents (index.html, index.wiki,
index.md, and 404.md). So the cache checks are only performed if
there's a valid hash (i.e. if "SELECT hash FROM unversioned" returns
non-empty data). Moreover, the Last-Modified response header was not
sent, if an ETag cache hit was already handled (though, at least my
Apache web server seems to purge the Last-Modified header from "304
Not Modified" responses).
(2) Updated If-Modified-Since checks
The updated patch also includes the modifications to the
If-Modified-Since checks, as suggested in a separate post.
--Florian
= Patch for Fossil [a7056e64] ==
Index: src/cgi.c
==
--- src/cgi.c
+++ src/cgi.c
@@ -249,11 +249,11 @@
iReplyStatus = 200;
zReplyStatus = "OK";
}
if( g.fullHttpReply ){
-fprintf(g.httpOut, "HTTP/1.0 %d %s\r\n", iReplyStatus, zReplyStatus);
+fprintf(g.httpOut, "HTTP/1.1 %d %s\r\n", iReplyStatus, zReplyStatus);
fprintf(g.httpOut, "Date: %s\r\n", cgi_rfc822_datestamp(time(0)));
fprintf(g.httpOut, "Connection: close\r\n");
fprintf(g.httpOut, "X-UA-Compatible: IE=edge\r\n");
}else{
fprintf(g.httpOut, "Status: %d %s\r\n", iReplyStatus, zReplyStatus);
@@ -269,10 +269,11 @@
fprintf(g.httpOut, "Cache-control: no-cache\r\n");
}
if( etag_mtime()>0 ){
fprintf(g.httpOut, "Last-Modified: %s\r\n",
cgi_rfc822_datestamp(etag_mtime()));
+fprintf(g.httpOut, "Vary: Cookie\r\n"); /* HTTP/1.0 (no ETags) */
}
if( blob_size()>0 ){
fprintf(g.httpOut, "%s", blob_buffer());
}
Index: src/doc.c
==
--- src/doc.c
+++ src/doc.c
@@ -641,17 +641,29 @@
}
}
if( isUV ){
if( db_table_exists("repository","unversioned") ){
Stmt q;
+char *zHash=0;
+sqlite3_int64 mtime=0;
db_prepare(, "SELECT hash, mtime FROM unversioned"
" WHERE name=%Q", zName);
if( db_step()==SQLITE_ROW ){
- etag_check(ETAG_HASH, db_column_text(,0));
- etag_last_modified(db_column_int64(,1));
+ zHash = fossil_strdup(db_column_text(,0));
+ mtime = db_column_int64(,1);
}
db_finalize();
+if( zHash ){
+ /* Only call etag_check() if the unversioned file was found
+ ** and has a valid hash, as doc_page() is called repeatedly
+ ** to search for index documents (index.html, index.wiki,
+ ** index.md, and 404.md), causing an assertion failure in
+ ** etag_check(), due to zETag already initialized. */
+ if( zHash[0] )
+etag_check(ETAG_HASH|ETAG_CEXP, zHash, mtime);
+ free(zHash);
+}
if( unversioned_content(zName, )==0 ){
rid = 1;
zDfltTitle = zName;
}
}
@@ -847,11 +859,11 @@
*/
void logo_page(void){
Blob logo;
char *zMime;
- etag_check(ETAG_CONFIG, 0);
+ etag_check(ETAG_CONFIG, 0, 0);
zMime = db_get("logo-mimetype", "image/gif");
blob_zero();
db_blob(, "SELECT value FROM config WHERE name='logo-image'");
if( blob_size()==0 ){
blob_init(, (char*)aLogo, sizeof(aLogo));
@@ -881,11 +893,11 @@
*/
void background_page(void){
Blob bgimg;
char *zMime;
- etag_check(ETAG_CONFIG, 0);
+ etag_check(ETAG_CONFIG, 0, 0);
zMime = db_get("background-mimetype", "image/gif");
blob_zero();
db_blob(, "SELECT value FROM config WHERE name='background-image'");
if( blob_size()==0 ){
blob_init(, (char*)aBackground, sizeof(aBackground));
Index: src/etag.c
==
--- src/etag.c
+++ src/etag.c
@@ -24,10 +24,11 @@
** (1) The mtime on the Fossil executable
** (2) The last change to the CONFIG table
** (3) The last change
