Re: [fossil-users] timeline vs. finfo date spacing
On 2 March 2015 at 17:53, jungle Boogie wrote: > https://www.fossil-scm.org/index.html/timeline?y=ci > > But there's also the fine info that displays the history of a file: > https://www.fossil-scm.org/index.html/finfo?name=src/db.c These links and the others are fine in Firefox but when rendered in Google Chrome, the date looks like this: 2015- 02-28 When viewed in Firefox, the date will display on one line: 2015-02-28 -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] timeline vs. finfo date spacing
Hello All, We're all familiar with the timeline: https://www.fossil-scm.org/index.html/timeline?y=ci But there's also the fine info that displays the history of a file: https://www.fossil-scm.org/index.html/finfo?name=src/db.c Is the spacing so much wider on file info to accommodate the linage tracing via ventricle and horizontal lines? Is there some css hack that would display it better? After looking at some less updated file, the date is also affected: https://www.fossil-scm.org/index.html/finfo?name=ajax/js/whajaj.js https://www.fossil-scm.org/index.html/finfo?name=ajax/index.html https://www.fossil-scm.org/index.html/finfo?name=autoconf/ax_check_openssl.m4 -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] SQLITE_ERROR: no such function: score
Hello!
On 2 March 2015 at 12:54, j. van den hoff wrote:
> something seems broken, currently (or what am I missing?):
>
> issuing `fossil search something' yields
>
> SQLITE_ERROR: no such function: score
> fossil: no such function: score: {INSERT INTO srch(rid,uuid,date,comment,x)
> SELECT blob.rid, uuid, datetime(event.mtime),
> coalesce(ecomment,comment), score(coalesce(ecomment,comment)) AS y
> FROM event, blobWHERE blob.rid=event.objid AND y>0;}
>
> happens with fossil version 1.31 [14302b6cc7] 2015-03-02 05:54:14 UTC
>
> under macos 10.9.5.
>
Dr. Hipp fixed!
http://fossil-scm.org/index.html/info/83509c149eb0542b
> thx/joerg
>
>
--
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
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 repolist argument with winsrv
Joe Mistachkin decía, en el mensaje "Re: [fossil-users] fossil repolist argument with winsrv" del 2/3/2015 19:48:22: > Sorry, minor oversight. It was not setting the right flag bit prior to > calling into the Win32 HTTP server. Should work on trunk now. Confirmed: it does. ___ 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 repolist argument with winsrv
Richie Adler wrote: > > This passes the --repolist parameter to the "fossil server" command recorded > in the registry, but I get a "Not found" page when I run the service installed > or even when I run > Sorry, minor oversight. It was not setting the right flag bit prior to calling into the Win32 HTTP server. Should work on trunk now. -- Joe Mistachkin ___ 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 repolist argument with winsrv
Joe Mistachkin decía, en el mensaje "Re: [fossil-users] fossil repolist argument with winsrv" del 2/3/2015 18:42:42: > > Petr Ferdus wrote: >> >> I just realized that fossil winsrv command does not recognize --repolist >> argument. Could winsrv honors this argument as well? >> > > Fixed on trunk. This passes the --repolist parameter to the "fossil server" command recorded in the registry, but I get a "Not found" page when I run the service installed or even when I run fossil server --repolist --port 8080 "D:\path\to\repo-directory" and I try to access localhost:8080 Can somebody else test in Windows the server command with the --repolist parameter? My configuration: fossil version 1.31 [a0b33ab4d4] 2015-03-02 21:41:52 UTC gcc (GCC) 4.7.2 Windows 7 Ultimate SP1 ___ 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] For your dscm-politik reading pleasure
On Mon, Mar 2, 2015 at 3:14 PM, Matt Welland wrote: > For example, if I clean up and move things around in a Fossil repo and by > force of habit do an update before a commit I *lose* some of my clean up > effort when Fossil (illogically IMHO) brings back the removed files. > Where I work, this issue is avoided by the use of "feature" (or issue) branches - that is, when one of us implements a new feature or fixes an issue, the work is done is a suitably named branch. Then the new/changed code is reviewed before merging into trunk. If another change is made to the same file(s), then which ever is reviewed/approved first will be merged first, then that will be merged in to the feature/issue branch. Then the second can be (re-)reviewed, then merged upon approval. However, I agree that "update" should not revert any pending changes, but, rather, cause warnings about potential conflicts. ___ 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] SQLITE_ERROR: no such function: score
On 2 March 2015 at 13:33, j. van den hoff wrote: > yes, same problem. but now reply to your post in the archive (and thus no > solution) it seems, no? That's the case for me in trunk. I don't know if there was a regression or if it didn't actually work in the past, though. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] build.wiki patch
And please: In the '2.0 Compiling/MinGW' paragraph a note about not
using MinGW-4.0 cause it breaks e.g. the "extras" command:
Index: www/build.wiki
==
--- www/build.wiki
+++ www/build.wiki
@@ -107,13 +107,16 @@
Unix without running "configure" → if you prefer to
avoid running configure, you
can also use: make -f Makefile.classic. You may want to make minor
edits to Makefile.classic to configure the build for your system.
-MinGW/MinGW-w64 → Use the mingw makefile:
+MinGW3.x (not 4.0)/MinGW-w64 → Use the mingw makefile:
"make -f win/Makefile.mingw". On a Windows box you will
need either Cygwin or Msys as build environment. On Cygwin, Linux
or Darwin you may want to make minor edits to win/Makefile.mingw
to configure the cross-compile environment.
+
+Hint: Don't use MinGW-4.0, it will compile but fossil won't work
+correctly, see
+href="https://www.fossil-scm.org/index.html/tktview/18cff45a4e210430e24c";>https://www.fossil-scm.org/index.html/tktview/18cff45a4e210430e24c.
MSVC → Use the MSVC makefile. First
change to the "win/" subdirectory ("cd win") then run
"nmake /f Makefile.msc".Alternatively, the batch
Am 01.03.2015 um 22:45 schrieb jungle Boogie:
Hello All,
Some slight corrections to the build.wiki page:
Index: www/build.wiki
==
--- www/build.wiki
+++ www/build.wiki
@@ -33,11 +33,11 @@
released versions of
fossil are available from the http://www.fossil-scm.org/download.html";>downloads page.
To obtain a development version of fossil, follow these steps:
-Point your web browser at
+Point your web browser to
http://www.fossil-scm.org/";>
http://www.fossil-scm.org/.
Click on the
http://www.fossil-scm.org/fossil/timeline";>Timeline
@@ -48,11 +48,11 @@
link.
Finally, click on one of the
"Zip Archive" or "Tarball" links, according to your preference.
These link will build a ZIP archive or a gzip-compressed tarball of the
-complete source code and download it to your browser.
+complete source code and download it to your computer.
Aside: Is it really safe to use an unreleased development version of
the Fossil source code?
@@ -66,11 +66,11 @@
repository change that prevent loss-of-work due to bugs.
The Fossil [./selfhost.wiki | self-hosting repositories], especially
the one at [http://www.fossil-scm.org/fossil], usually run a version
of trunk that is less than a week or two old. Look at the bottom
-right-hand corner of this screen (to the right of "This page was
+left-hand corner of this screen (to the right of "This page was
generated in...") to see exactly which version of Fossil is
rendering this page. It is always safe to use whatever version
of the Fossil code you find running on the main Fossil website.
2.0 Compiling
___
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] server.wiki patch
Hi Michai, On 2 March 2015 at 13:20, Michai Ramakers wrote: > On 1 March 2015 at 20:52, jungle Boogie wrote: Minor patch to add information about inetd on FreeBSD to the server.wiki page. ... > > Please see whether [fbbf640b] is ok for you. > Yes, this is great for me and more straight forward. I did amend the title slightly, too, but I'm not very particular if you update that. > Michai -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 repolist argument with winsrv
Petr Ferdus wrote: > > I just realized that fossil winsrv command does not recognize --repolist > argument. Could winsrv honors this argument as well? > Fixed on trunk. -- Joe Mistachkin ___ 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] SQLITE_ERROR: no such function: score
On Mon, 02 Mar 2015 22:16:40 +0100, jungle Boogie
wrote:
Hi j. van den hoff,
On 2 March 2015 at 12:54, j. van den hoff
wrote:
something seems broken, currently (or what am I missing?):
issuing `fossil search something' yields
SQLITE_ERROR: no such function: score
fossil: no such function: score: {INSERT INTO
srch(rid,uuid,date,comment,x)
SELECT blob.rid, uuid, datetime(event.mtime),
coalesce(ecomment,comment), score(coalesce(ecomment,comment))
AS y
FROM event, blobWHERE blob.rid=event.objid AND y>0;}
happens with fossil version 1.31 [14302b6cc7] 2015-03-02 05:54:14 UTC
under macos 10.9.5.
See this post by me about fossil search from last month:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19060.html
yes, same problem. but now reply to your post in the archive (and thus no
solution) it seems, no?
thx/joerg
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] For your dscm-politik reading pleasure
On Mon, Mar 2, 2015 at 1:37 PM, jungle Boogie wrote: > Hi Matt, > On 2 March 2015 at 12:14, Matt Welland wrote: > > The basic point made in the post by Mark Shuttleworth (in 2007 BTW) is a > > good one. > > > > Cleaning up or refactoring is hard to do and ideally an SCM tool helps > the > > process. Tools that behave inconsistent with expectations induce > legitimate > > FUD leading to reluctance to clean up. There might be some areas where > > Fossil could be improved in this regard. For example, if I clean up and > move > > things around in a Fossil repo and by force of habit do an update before > a > > commit I *lose* some of my clean up effort when Fossil (illogically IMHO) > > brings back the removed files. A minor setback that chips away at the > > willingness and enthusiasm developers have towards refactoring. > > > > I just tested this and my very simple test, this is what I found out: > you need to fossil rm X > rm X > fossil commit -m "deleted file X" > > Has that also been your experience? > My previous experience was: fossil rm X rm X fossil update # X comes back But I just tried to reproduce this removed files coming back behavior using our officially installed 1.28 version of fossil and the file does *not* come back. I've had complaints about this fairly recently but since I can't reproduce it I assume the user involved was accidentally pointing to an older version of fossil. My mistake. Ignore my comment. > > > > Just my $0.02. > > > > > -- > --- > inum: 883510009027723 > sip: jungleboo...@sip2sip.info > xmpp: jungle-boo...@jit.si > ___ > 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] server.wiki patch
On 1 March 2015 at 20:52, jungle Boogie wrote: >>> >>> Minor patch to add information about inetd on FreeBSD to the server.wiki >>> page. >>> >>> ... Please see whether [fbbf640b] is ok for you. Michai ___ 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] SQLITE_ERROR: no such function: score
Hi j. van den hoff,
On 2 March 2015 at 12:54, j. van den hoff wrote:
> something seems broken, currently (or what am I missing?):
>
> issuing `fossil search something' yields
>
> SQLITE_ERROR: no such function: score
> fossil: no such function: score: {INSERT INTO srch(rid,uuid,date,comment,x)
> SELECT blob.rid, uuid, datetime(event.mtime),
> coalesce(ecomment,comment), score(coalesce(ecomment,comment)) AS y
> FROM event, blobWHERE blob.rid=event.objid AND y>0;}
>
> happens with fossil version 1.31 [14302b6cc7] 2015-03-02 05:54:14 UTC
>
> under macos 10.9.5.
>
See this post by me about fossil search from last month:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19060.html
> thx/joerg
>
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] filtering out "Execute permission set" lines
In the check-in Info page, the changes section sometimes has "Execute permission set" lines. This confuses non-developer people. Is there a way to filter this out? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil repolist argument with winsrv
I just realized that fossil winsrv command does not recognize --repolist argument. Could winsrv honors this argument as well? Thanks Peter ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SQLITE_ERROR: no such function: score
something seems broken, currently (or what am I missing?):
issuing `fossil search something' yields
SQLITE_ERROR: no such function: score
fossil: no such function: score: {INSERT INTO
srch(rid,uuid,date,comment,x) SELECT blob.rid, uuid,
datetime(event.mtime), coalesce(ecomment,comment),
score(coalesce(ecomment,comment)) AS y FROM event, blobWHERE
blob.rid=event.objid AND y>0;}
happens with fossil version 1.31 [14302b6cc7] 2015-03-02 05:54:14 UTC
under macos 10.9.5.
thx/joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] For your dscm-politik reading pleasure
Hi Matt, On 2 March 2015 at 12:14, Matt Welland wrote: > The basic point made in the post by Mark Shuttleworth (in 2007 BTW) is a > good one. > > Cleaning up or refactoring is hard to do and ideally an SCM tool helps the > process. Tools that behave inconsistent with expectations induce legitimate > FUD leading to reluctance to clean up. There might be some areas where > Fossil could be improved in this regard. For example, if I clean up and move > things around in a Fossil repo and by force of habit do an update before a > commit I *lose* some of my clean up effort when Fossil (illogically IMHO) > brings back the removed files. A minor setback that chips away at the > willingness and enthusiasm developers have towards refactoring. > I just tested this and my very simple test, this is what I found out: you need to fossil rm X rm X fossil commit -m "deleted file X" Has that also been your experience? > Just my $0.02. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 http' seems to output a page multiple times on amd64 (?)
Hello,
On 2 March 2015 at 11:18, Michai Ramakers wrote:
> Hello,
>
> while playing around with Fossil from inetd, saw some weirdness on
> trunk tip ([14302b6cc7]) between amd64 and x86 linux and netbsd.
>
> Narrowing it down a bit, I did the following:
>
> ./fossil new test.fossil
> ( echo 'GET /index HTTP/1.1'; echo 'Host: localhost'; echo ) |
> ./fossil http test.fossil > $my_output_file
>
>
> I tried to debug this a bit, but it's not exactly trivial what happens
> during page generation (for me).
>
I have the same results as you did with a,c,d with freebsd
10-1-release on i386 hardware.
I don't know what the end result should be, unfortunately, but having
different results is quite interesting.
> Any ideas?
>
> Michai
>
--
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
HTTP/1.0 200 OK
Date: Mon, 2 Mar 2015 20:06:09 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 1413
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
function gebi(x){
if(x.substr(0,1)=='#') x = x.substr(1);
var e = document.getElementById(x);
if(!e) throw new Error('Expecting element with ID '+x);
else return e;}
This is a stub home-page for the project.
To fill in this page, first go to
setup/config
and establish a "Project Name". Then create a
wiki page with that name. The content of that wiki page
will be displayed in place of this message.
This page was generated in about
0.007s by
Fossil version [14302b6cc7] 2015-03-02 05:54:14
HTTP/1.0 200 OK
Date: Mon, 2 Mar 2015 20:06:09 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 2826
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
function gebi(x){
if(x.substr(0,1)=='#') x = x.substr(1);
var e = document.getElementById(x);
if(!e) throw new Error('Expecting element with ID '+x);
else return e;}
This is a stub home-page for the project.
To fill in this page, first go to
setup/config
and establish a "Project Name". Then create a
wiki page with that name. The content of that wiki page
will be displayed in place of this message.
This page was generated in about
0.007s by
Fossil version [14302b6cc7] 2015-03-02 05:54:14
function gebi(x){
if(x.substr(0,1)=='#') x = x.substr(1);
var e = document.getElementById(x);
if(!e) throw new Error('Expecting element with ID '+x);
else return e;}
This is a stub home-page for the project.
To fill in this page, first go to
setup/config
and establish a "Project Name". Then create a
wiki page with that name. The content of that wiki page
will be displayed in place of this message.
This page was generated in about
0.009s by
Fossil version [14302b6cc7] 2015-03-02 05:54:14
___
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] For your dscm-politik reading pleasure
On Mon, Mar 2, 2015 at 11:46 AM, bch wrote: > Renames as first-class dscm operations: > > http://www.markshuttleworth.com/archives/123 > The basic point made in the post by Mark Shuttleworth (in 2007 BTW) is a good one. Cleaning up or refactoring is hard to do and ideally an SCM tool helps the process. Tools that behave inconsistent with expectations induce legitimate FUD leading to reluctance to clean up. There might be some areas where Fossil could be improved in this regard. For example, if I clean up and move things around in a Fossil repo and by force of habit do an update before a commit I *lose* some of my clean up effort when Fossil (illogically IMHO) brings back the removed files. A minor setback that chips away at the willingness and enthusiasm developers have towards refactoring. Just my $0.02. > > -bch > ___ > 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 http' seems to output a page multiple times on amd64 (?)
On 2 March 2015 at 20:18, Michai Ramakers wrote:
>
> ...on 4 boxes:
>
> (a) netbsd amd64 kernel on amd64 CPU ('nbsd_amd64')
> (b) netbsd x86 kernel on x86 CPU ('nbsd_x86')
> (c) linux amd64 kernel on amd64 CPU ('lin_amd64')
> (d) linux x86 kernel on amd64 CPU ('lin_x86_on_amd64')
actually (b) is also a 64-bit CPU but running a 32-bit kernel, jeez,
didn't even know.
Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 'fossil http' seems to output a page multiple times on amd64 (?)
Hello,
while playing around with Fossil from inetd, saw some weirdness on
trunk tip ([14302b6cc7]) between amd64 and x86 linux and netbsd.
Narrowing it down a bit, I did the following:
./fossil new test.fossil
( echo 'GET /index HTTP/1.1'; echo 'Host: localhost'; echo ) |
./fossil http test.fossil > $my_output_file
...on 4 boxes:
(a) netbsd amd64 kernel on amd64 CPU ('nbsd_amd64')
(b) netbsd x86 kernel on x86 CPU ('nbsd_x86')
(c) linux amd64 kernel on amd64 CPU ('lin_amd64')
(d) linux x86 kernel on amd64 CPU ('lin_x86_on_amd64')
Only on the x86 machine ('b') did I see the expected HTML-output; the
others displayed the same page multiple times. Output-files are
attached.
Machine-info for all 4 boxes:
(a) NetBSD 6.0.1 (GENERIC) amd64
(b) NetBSD 6.1.4 (GENERIC) i386
(c) Linux 3.14.28-1-lts #1 SMP Thu Jan 8 21:04:11 CET 2015 x86_64
unknown unknown GNU/Linux
(d) Linux 3.18.2-2-ARCH #1 SMP PREEMPT Fri Jan 9 07:23:08 CET 2015
i686 GNU/Linux
I tried to debug this a bit, but it's not exactly trivial what happens
during page generation (for me).
Any ideas?
Michai
HTTP/1.0 200 OK
Date: Mon, 2 Mar 2015 18:35:10 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 1413
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
function gebi(x){
if(x.substr(0,1)=='#') x = x.substr(1);
var e = document.getElementById(x);
if(!e) throw new Error('Expecting element with ID '+x);
else return e;}
This is a stub home-page for the project.
To fill in this page, first go to
setup/config
and establish a "Project Name". Then create a
wiki page with that name. The content of that wiki page
will be displayed in place of this message.
This page was generated in about
0.001s by
Fossil version [14302b6cc7] 2015-03-02 05:54:14
HTTP/1.0 200 OK
Date: Mon, 2 Mar 2015 18:35:10 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 2826
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
function gebi(x){
if(x.substr(0,1)=='#') x = x.substr(1);
var e = document.getElementById(x);
if(!e) throw new Error('Expecting element with ID '+x);
else return e;}
This is a stub home-page for the project.
To fill in this page, first go to
setup/config
and establish a "Project Name". Then create a
wiki page with that name. The content of that wiki page
will be displayed in place of this message.
This page was generated in about
0.001s by
Fossil version [14302b6cc7] 2015-03-02 05:54:14
function gebi(x){
if(x.substr(0,1)=='#') x = x.substr(1);
var e = document.getElementById(x);
if(!e) throw new Error('Expecting element with ID '+x);
else return e;}
This is a stub home-page for the project.
To fill in this page, first go to
setup/config
and establish a "Project Name". Then create a
wiki page with that name. The content of that wiki page
will be displayed in place of this message.
This page was generated in about
0.001s by
Fossil version [14302b6cc7] 2015-03-02 05:54:14
HTTP/1.0 200 OK
Date: Mon, 2 Mar 2015 18:37:15 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 1413
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
function gebi(x){
if(x.substr(0,1)=='#') x = x.substr(1);
var e = document.getElementById(x);
if(!e) throw new Error('Expecting element with ID '+x);
else return e;}
This is a stub home-page for the project.
To fill in this page, first go to
setup/config
and establish a "Project Name". Then create a
wiki page with that name. The content of that wiki page
will be displayed in place of this message.
This page was generated in about
0.001s by
Fossil version [14302b6cc7] 2015-03-02 05:54:14
HTTP/1.0 200 OK
Date: Mon, 2 Mar 2015 18:37:15 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 2826
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
http://localhost/index"; />
Unnamed Fossil Project: Home
Unnamed Fossil ProjectHome
Not logged in
Home
Timeline
Files
Branches
Tags
Tickets
Wiki
Login
f
Re: [fossil-users] Fossil 1.31 directory name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Feb 24, 2015 at 12:02 PM, Richard Hipp wrote: > On 2/24/15, Andy Goth wrote: >> Unlike previous releases, the unpacked directory name does not >> contain the seconds. This means the directory and archive >> filenames don't match, which is a problem for the SlackBuild >> script. >> >> Are there any plans to reupload with the directory renamed > > I'll get to that as I am able. We have a bug in SQLite right now. > You are in queue Quite some time has passed. I assume you're not going to reupload, and we're stuck with the directory name as it is, at least for this release. On 2/24/2015 11:31 AM, Joe Prostko wrote: > Yes, I wondered about the directory name not matching the > filename, but just modified my Haiku build recipe to account for > it. I'll be sure to change the recipe file once the tar.gz with > the full path is in place. When I have time, I'll have to do the same for the SlackBuild script. - -- Andy Goth | -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU9LC8AAoJELtYwrrr47Y46W0IANwjkJ5ciNZ9te1SA+JJS6rN ZMJ5/f5st7pgj8POkcI6G4Y6WQzNtqHbq06uON8llrVPSEZfyQLlI5cxd52QPIjd 0soz8wAjfBf3XT/tCf4OcnhSa2QRSSjy5saH2agle7KxyQoKbsIyRrcPl6u4AkY5 yTrKXHl1GSbgyNgUtGHfH3hdbjtIgIevrEytJmHXJKhqi04orbwG17AyU0BO6n+9 5agEsZiuRL4zROGu/bu9FSyq2f0wLzQcTHiM0dkJVVqnr24G2b1/KoSD83oOZnVg Wgf7iEy7lSLWT1uhhOn3YyZGQBCqBwnhMQK6ZmmpPaWZmnDPY90Fr48sIFO74Mg= =XYFe -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] For your dscm-politik reading pleasure
Renames as first-class dscm operations: http://www.markshuttleworth.com/archives/123 -bch ___ 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 2.1: Scaling
On Mon, Mar 02, 2015 at 11:38:38AM -0500, Richard Hipp wrote: > On 3/2/15, Joerg Sonnenberger wrote: > > On Mon, Mar 02, 2015 at 07:30:44AM -0500, Richard Hipp wrote: > >> So I was thinking, could Fossil 2.0 be enhanced in ways to support > >> scaling to the point where it works on really massive projects? > > > > I think the single biggest practical issue right now still goes back to > > the baseline manifests not being efficient enough. Would you consider > > changing the rules to allow truely incremental manifests? I agree that > > having full manifests is sometimes nicer, but I think those would be > > build on-demand and cached separately. I belive that is the majority of > > the current meta data, which matters a lot whenever a rebuild happens. > > > > The current mechanism is to have periodic full baseline manifests, and > then have deltas against those baselines in between. Hence, no more > than two artifacts ever need to be decoded in order to access a > manifest - the baseline and its delta. I know. The manifest contains two parts: non-file content and the file list. For delta manifests, the file list is encoded as changes relative to the base line. > Are you proposing to have deltas of deltas, so that a potentially > large number of artifacts need to be decoded in order to reconstruct > the complete manifest? I think we have two different situations when it comes to access the file list: (1) Getting the full list. This is primarily used for initial checks and as part of the status handling of checkouts, maybe also for the web view. (2) Getting the changes relative to another checkin. This is what update etc. is interested in. The problem with the base line encoding is that it still has a high degree of redundancy. While delta compression removes a good chunk of the overhead in terms of disk space, rebuild still has to process the full amount. That's a significant part for a large tree. My suggestion is to store a plain file delta in the manifest. Let's call this is a pure delta manifest. Rebuild parsing is then linear in the number of changed files. The plink table is a direct mapping of the pure delta manifest, they have effectively the same data. To keep the performance of case (1) above, a new full manifest table is stored separate and computed on demand. That can be either during rebuild or on first access. Heuristics like "X commits since last full manifest" can be applied. This is a (local) cache, no need to transfer it via sync protocol, no need to preserve it during rebuild either. Joerg ___ 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] inetd-server + multiple repos
Hi Michai, On 2 March 2015 at 09:19, Michai Ramakers wrote: > right. Port numbers work too on netbsd, but I'll amend the server.wiki > to make this a bit clear, I guess. Keep up the great work! Best! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] inetd-server + multiple repos
On 2 March 2015 at 18:10, jungle Boogie wrote: > Hi Michai, > On 2 March 2015 at 07:03, Michai Ramakers wrote: >> >> Unless someone has a quick clue, I can bisect it later today. But >> probably it's user error. >> > > Do you see inetd started on port 12345? it works now, sort of, thanks. > Only spending ~60 seconds reviewing this, the netbsd doc looks very > similar to freebsd where is says what you have listed in /etc/inetd > needs to be in /etc/services and reference it by a name in /etc/inetd: > https://www.netbsd.org/docs/guide/en/chap-inetd.html right. Port numbers work too on netbsd, but I'll amend the server.wiki to make this a bit clear, I guess. Michai ___ 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] inetd-server + multiple repos
Hi Michai, On 2 March 2015 at 07:03, Michai Ramakers wrote: > Hello, > > toying a bit with Fossil serving through inetd, as per > http://fossil-scm.org/xfer/doc/trunk/www/server.wiki , for some reason > I can't get the example shown on that page working when using a > directory-with-multiple-repos as last argument, instead of a single > repo, e.g. > > stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /my/fossils > > I could have sworn this worked at some time. Normally I run Fossil as > CGI-binary instead, so this is not something I have tested for a > while. > > Unless someone has a quick clue, I can bisect it later today. But > probably it's user error. > Do you see inetd started on port 12345? After I figured out the /etc/services thing for my, it worked as expected. Only spending ~60 seconds reviewing this, the netbsd doc looks very similar to freebsd where is says what you have listed in /etc/inetd needs to be in /etc/services and reference it by a name in /etc/inetd: https://www.netbsd.org/docs/guide/en/chap-inetd.html Hope that helps! > Thanks, > Michai Best, sean -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 2.1: Scaling
On 3/2/15, Joerg Sonnenberger wrote: > On Mon, Mar 02, 2015 at 07:30:44AM -0500, Richard Hipp wrote: >> So I was thinking, could Fossil 2.0 be enhanced in ways to support >> scaling to the point where it works on really massive projects? > > I think the single biggest practical issue right now still goes back to > the baseline manifests not being efficient enough. Would you consider > changing the rules to allow truely incremental manifests? I agree that > having full manifests is sometimes nicer, but I think those would be > build on-demand and cached separately. I belive that is the majority of > the current meta data, which matters a lot whenever a rebuild happens. > The current mechanism is to have periodic full baseline manifests, and then have deltas against those baselines in between. Hence, no more than two artifacts ever need to be decoded in order to access a manifest - the baseline and its delta. Are you proposing to have deltas of deltas, so that a potentially large number of artifacts need to be decoded in order to reconstruct the complete manifest? I don't understand how that would help. Can you provide more explanation? -- 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 2.1: Scaling
On Mon, Mar 02, 2015 at 07:30:44AM -0500, Richard Hipp wrote: > So I was thinking, could Fossil 2.0 be enhanced in ways to support > scaling to the point where it works on really massive projects? I think the single biggest practical issue right now still goes back to the baseline manifests not being efficient enough. Would you consider changing the rules to allow truely incremental manifests? I agree that having full manifests is sometimes nicer, but I think those would be build on-demand and cached separately. I belive that is the majority of the current meta data, which matters a lot whenever a rebuild happens. Joerg ___ 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] inetd-server + multiple repos
On 3/2/15, Michai Ramakers wrote:
> Hello,
>
> toying a bit with Fossil serving through inetd, as per
> http://fossil-scm.org/xfer/doc/trunk/www/server.wiki , for some reason
> I can't get the example shown on that page working when using a
> directory-with-multiple-repos as last argument, instead of a single
> repo, e.g.
>
> stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http
> /my/fossils
>
> I could have sworn this worked at some time. Normally I run Fossil as
> CGI-binary instead, so this is not something I have tested for a
> while.
I do this using xinetd on Ubuntu on my desktop. Works fine for me.
My /etc/xinetd.d/http-alt file says:
service http-alt
{
port = 591
socket_type = stream
wait = no
user = root
server = /home/drh/bin/fossil
server_args = http /home/drh/www/repos/ --errorlog /errors.txt
--localauth --files * --repolist
}
>
> Unless someone has a quick clue, I can bisect it later today. But
> probably it's user error.
>
> Thanks,
> Michai
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
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
[fossil-users] inetd-server + multiple repos
Hello, toying a bit with Fossil serving through inetd, as per http://fossil-scm.org/xfer/doc/trunk/www/server.wiki , for some reason I can't get the example shown on that page working when using a directory-with-multiple-repos as last argument, instead of a single repo, e.g. stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /my/fossils I could have sworn this worked at some time. Normally I run Fossil as CGI-binary instead, so this is not something I have tested for a while. Unless someone has a quick clue, I can bisect it later today. But probably it's user error. Thanks, Michai ___ 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] inetd-server + multiple repos
correction, On 2 March 2015 at 16:03, Michai Ramakers wrote: > > stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /my/fossils should be: 12345 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /my/fossils Michai ___ 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 2.1: Scaling
On 3/2/15, Richard Boehme wrote: > One question that arises is: how do I define what a "server" is? Can I > get the complete repository history for everything else but get a more > limited history for files that are larger than a certain size, or that > have certain extensions? That is theoretically possible given the file format. It is simply a question of writing the necessary code to implement that capability. > > How would this work with sub-repositories (sorry, not versed very well > in fossil, but I understand that there can be sub respositories that > are nested under the main one (for instance for a directory which > contains a lot of videos or images)) > I think sub-repositories is an orthogonal topic. -- 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 2.1: Scaling
One question that arises is: how do I define what a "server" is? Can I get the complete repository history for everything else but get a more limited history for files that are larger than a certain size, or that have certain extensions? How would this work with sub-repositories (sorry, not versed very well in fossil, but I understand that there can be sub respositories that are nested under the main one (for instance for a directory which contains a lot of videos or images)) Thanks. Richard On 3/2/15, Richard Hipp wrote: > Ben Pollack's essay at > http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ > succinctly points up some of the problems with DVCS versus centralized > VCS (like subversion). Much further discussion occurs on the various > news aggregator sites. > > So I was thinking, could Fossil 2.0 be enhanced in ways to support > scaling to the point where it works on really massive projects? > > The key idea would be to relax the requirement that each client load > the entire history of the project. Instead, a clone would only load a > limited amount of history (a month, a year, perhaps even just the most > recent check-in). This would make cloning much faster and the > resulting clone much smaller. Missing content could be downloaded > from the server on an as-needed basis. So, for example, if the user > does "fossil update trunk:2010-01-01" then the local client would > first have to go back to the server to fetch content from 2010. The > additional content would be added to the local repository. And so the > repository would still grow. But it grows only on an as-needed basis > rather than starting out at full size. And in the common case where > the developer never needs to look at any content over a few months > old, the growth is limited. > > By downloading the meta-data that is currently computed locally by > "rebuild", many operations on older content, such as timelines or > search, could be performed even without having the data present. In > the "bsd-src.fossil" repository, the content is 78% of the repository > file and the meta-data is the other 22%. So a clone that stored only > the most recent content together with all metadata might be about > 1/4th the size of a full clone. For even greater savings, perhaps the > metadata could be time-limited, though not as severely as the content. > So perhaps the clone would only initialize to the last month of > content and the last five years of metadata. > > For "wide" repositories (such as bsd-src) that hold many thousands of > files in a single check-out, Fossil could be enhanced to allow > cloning, checkout, and commit of just a small slice of the entire > tree. So, for example, a clone might hold just the bin/ subdirectory > of bsd-src containing just 56 files, rather than all 147720 files of a > complete check-out. Fossil should be able to do everything it > normally does with just this subset, including commit changes, except > that on new manifests generated by the commit, the R-card would have > to be omitted since the entire tree is necessary to compute the > R-card. But the R-card is optional already, controlled by the > "repo-cksum" setting, which is turned off in bsd-src, so there would > be no loss in functionality. > > Tickets and wiki in a clone might be similarly limited to (say) the > previous 12 months of content, or the most recent change, whichever is > larger. > > With these kinds of changes, it seems like Fossil might be made to > scale to arbitrarily massive repositories on the client side. On the > server side, the current design would work until the repository grew > too big to fit into a single disk file, at which point the server > would need to be redesigned to use a client/server database like, > PostgreSQL, that can scale to sizes larger than the 140 terabyte limit > of SQLite. But that would be a really big repo. 22 years of BSD > history fits in 7.2 GB, or 61 GB uncompressed. So it would take a > rather larger project to get into the terabyte range. > > The sync protocol would need to be greatly enhanced to support this > functionality. Also, the schema for the meta-data, which currently is > an implementation detail, would need to become part of the interface. > Exposing the meta-data as interface would have been unthinkable a few > years ago, but at this point we have accumulated enough experience > about what is needed in the meta-data to perhaps make exposing its > design a reasonable alternative. > > These are just thoughts to elicit comments and discussion. I have > several unrelated and much higher-priority tasks to keep me busy at > the moment, so this is not something that would happen right away, > unless somebody else steps up to do a lot of the implementation work. > > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org
[fossil-users] Fossil 2.1: Scaling
Ben Pollack's essay at http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ succinctly points up some of the problems with DVCS versus centralized VCS (like subversion). Much further discussion occurs on the various news aggregator sites. So I was thinking, could Fossil 2.0 be enhanced in ways to support scaling to the point where it works on really massive projects? The key idea would be to relax the requirement that each client load the entire history of the project. Instead, a clone would only load a limited amount of history (a month, a year, perhaps even just the most recent check-in). This would make cloning much faster and the resulting clone much smaller. Missing content could be downloaded from the server on an as-needed basis. So, for example, if the user does "fossil update trunk:2010-01-01" then the local client would first have to go back to the server to fetch content from 2010. The additional content would be added to the local repository. And so the repository would still grow. But it grows only on an as-needed basis rather than starting out at full size. And in the common case where the developer never needs to look at any content over a few months old, the growth is limited. By downloading the meta-data that is currently computed locally by "rebuild", many operations on older content, such as timelines or search, could be performed even without having the data present. In the "bsd-src.fossil" repository, the content is 78% of the repository file and the meta-data is the other 22%. So a clone that stored only the most recent content together with all metadata might be about 1/4th the size of a full clone. For even greater savings, perhaps the metadata could be time-limited, though not as severely as the content. So perhaps the clone would only initialize to the last month of content and the last five years of metadata. For "wide" repositories (such as bsd-src) that hold many thousands of files in a single check-out, Fossil could be enhanced to allow cloning, checkout, and commit of just a small slice of the entire tree. So, for example, a clone might hold just the bin/ subdirectory of bsd-src containing just 56 files, rather than all 147720 files of a complete check-out. Fossil should be able to do everything it normally does with just this subset, including commit changes, except that on new manifests generated by the commit, the R-card would have to be omitted since the entire tree is necessary to compute the R-card. But the R-card is optional already, controlled by the "repo-cksum" setting, which is turned off in bsd-src, so there would be no loss in functionality. Tickets and wiki in a clone might be similarly limited to (say) the previous 12 months of content, or the most recent change, whichever is larger. With these kinds of changes, it seems like Fossil might be made to scale to arbitrarily massive repositories on the client side. On the server side, the current design would work until the repository grew too big to fit into a single disk file, at which point the server would need to be redesigned to use a client/server database like, PostgreSQL, that can scale to sizes larger than the 140 terabyte limit of SQLite. But that would be a really big repo. 22 years of BSD history fits in 7.2 GB, or 61 GB uncompressed. So it would take a rather larger project to get into the terabyte range. The sync protocol would need to be greatly enhanced to support this functionality. Also, the schema for the meta-data, which currently is an implementation detail, would need to become part of the interface. Exposing the meta-data as interface would have been unthinkable a few years ago, but at this point we have accumulated enough experience about what is needed in the meta-data to perhaps make exposing its design a reasonable alternative. These are just thoughts to elicit comments and discussion. I have several unrelated and much higher-priority tasks to keep me busy at the moment, so this is not something that would happen right away, unless somebody else steps up to do a lot of the implementation work. -- 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
