Re: [fossil-users] Linux/Windows USB
Hi Martin, Thanks! Your solution is elegant, works and was just what was required. Henk On Fri, Jul 26, 2013 at 4:41 PM, Martin Gagnon eme...@gmail.com wrote: On Fri, Jul 26, 2013 at 10:38:50AM +0200, henk harmsen wrote: At work I have a Windows 7 laptop, at home a Linux Debian system on which I do the real work. No network traffic is allowed but the files may be put on an encrypted USB. So my fossils are on the USB. The problem that I am facing is that the Debian path starts with /media/usb/mydir, whereas in Windows that is G:\mydir. So, fossil status gives : current directory is not within an open checkout. Is there a workaround for this? You could use the distributed nature of fossil and only put the repository on your usb key (the .fossil) and make a clone on your 2 systems. With autosync, everytime you commit or update, you get your change synced on your usb key. Or another alternative, if you are not allowed to have a clone on your system at home, you could open a check on the usb key for your system at home, and make a clone on your windows 7 laptop at work. So that way, you never use a checkout on 2 different system. An advantage of this is that you have some backup of your work, so if you loose you usb or something happens with your laptop, you are safe. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux/Windows USB
Thanks Andy. This works. In the end i just keep the repository on the USB, make 2 clones and keep one clone on each platform. Henk On Sat, Jul 27, 2013 at 2:46 AM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Edward Berner on Fri, 26 Jul 2013 16:49:45 -0700: So... try keeping your repository one directory above your checkout and opening it as fossil open ../repo.fossil and see if both platforms are happy with that. This is what one gets using relative paths: $ fossil open ../new.fossil $ f info project-name: unnamed repository: /tmp/new/../new.fossil local-root: /tmp/new/ ... $ f open ./new.fossil $ f info project-name: unnamed repository: /tmp/./new.fossil local-root: /tmp/ ... Andy -- TAI64 timestamp: 400051f3187a ___ 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] Linux/Windows USB
Thanks Edward, This works indeed. in the end the solution was to keep only the repository on the usb and create a checkout on each platform. Henk On Sat, Jul 27, 2013 at 1:49 AM, Edward Berner e...@bernerfam.com wrote: On 7/26/2013 1:38 AM, henk harmsen wrote: At work I have a Windows 7 laptop, at home a Linux Debian system on which I do the real work. No network traffic is allowed but the files may be put on an encrypted USB. So my fossils are on the USB. The problem that I am facing is that the Debian path starts with /media/usb/mydir, whereas in Windows that is G:\mydir. So, fossil status gives : current directory is not within an open checkout. Is there a workaround for this? If you open the repository using a relative path I think Fossil will remember the relative path (it used to convert it to an absolute path but that changed some time ago). Also, some aspects of Windows can handle forward-slashes in filenames. So... try keeping your repository one directory above your checkout and opening it as fossil open ../repo.fossil and see if both platforms are happy with that. -- Edward Berner ___ 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] Linux/Windows USB
Thanks! The solution that was easiest to implement was to keep just the repo on the USB and make checkins on each platform. Henk On Sat, Jul 27, 2013 at 12:21 AM, renework renew...@xs4all.nl wrote: Verzonden vanaf Samsung Mobile Original message From: renework renew...@xs4all.nl Date: To: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Linux/Windows USB Install “mingw and msys and make a mount g:mydir /your/path/on/debian. Original message From: henk harmsen h...@carbonmetrics.com Date: To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Linux/Windows USB At work I have a Windows 7 laptop, at home a Linux Debian system on which I do the real work. No network traffic is allowed but the files may be put on an encrypted USB. So my fossils are on the USB. The problem that I am facing is that the Debian path starts with /media/usb/mydir, whereas in Windows that is G:\mydir. So, fossil status gives : current directory is not within an open checkout. Is there a workaround for this? Henk ___ 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 ___ 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] admin pages are empty and have bad titles
I've resolved this. I'll share my outcome for future folks who want to get a low-maintenance fossil HTTPS server up quickly. The initial scheme was to use 'stunnel' as a reverse proxy to terminate SSL, and forward the request on to the fossil web server daemon that is listening on the same box. Here's the stunnel config I initially came up with: = pid = /home/fossil/stunnel.pid [fossil-https] accept = 10443 cert = /home/fossil/mysite.com.pem connect = localhost:10080 = And, again, here is how I was running fossil: /usr/local/bin//fossil server /home/fossil/repo.fossil -P 10080 --baseurl https://mysite.com:10443/ The baseurl here is required under this scheme. If it were not given, then when fossil sends a redirect page it would send urls like http://mysite.com:10080/, because fossil thinks it is speaking HTTP and that the server is on port 10080. So the remote browser would follow the redirect to the wrong L4 endpoint. The thing mostly works, except that it does not handle the extra slash it receives in some URLs, e.g. on the links from the Admin page. (I believe fossil's name resolution behavior here is defensible under RFC2616, by the way -- the RFC says that you compare URLs octet-for-octet with one narrow exception that does not apply here. So, in other words, adding a slash to a URL path changes the URL. So the problem was the URL my browser is sending in the first place, or in the URL that fossil was putting in the HREF in the HTML it was serving.) I considered chasing this further by hacking in the code or looking at getting a real industrial web server up. But I saw that DRH had responded to some previous question that the official fossil web site itself is also served by HTTPS, which made me think I was overcomplicating things. So I tried going for a different scheme in which stunnel behaves a bit more like xinetd, and used fossil's supporting feature for that: = pid = /home/fossil/stunnel.pid output = /home/fossil/stunnel.log [fossil-https] accept = 10443 cert = /home/fossil/mysite.com.pem exec = /usr/local/bin/fossil execargs = fossil http /home/fossil/repo.fossil --https --host mysite.com:10443 = I.e. fork one fossil process per request. This appears to Just Work and is probably what the fossil devs had initially intended. From a look at the code, by the way, the --https argument there is required to prevent fossil from thinking that it should not authenticate the user. Eric On Wed, Jul 24, 2013 at 10:06 PM, Andy Bradford amb-sendok-137730.cdeapjlkdpclmgfol...@bradfords.org wrote: Thus said Eric Rubin-Smith on Wed, 24 Jul 2013 10:55:24 -0400: Am I doing something wrong with my configs, or is a code change warranted? That's hard to say since I don't know under what conditions --baseurl is intended to be used (I know the docs say reverse proxy, but I haven't ever set one up so I don't understand all the fine details). The one time I tried to use it, I was doing it wrong: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12107.html In my case, however, I was using ``fossil http'' not ``fossil server'' and when I got rid of the --baseurl option, things worked as expected. In your case, you are trying to setup a reverse proxy... if you could provide some details about to setup a reverse proxy similar to your configuration (perhaps it is done with Apache), it might be easier for someone to reproduce. Have you tried using it without --baseurl? If so, what happened? Thanks, Andy -- TAI64 timestamp: 400051f08852 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] cvs to git to fossil does not preserve user names on check-ins
I exported my CVS repo to git using cvs2git (version 2.4.0-dev), and
ingested the resulting git repo into fossil according to the instructions
on the fossil web site, using fossil 1.26. My git version is 1.7.7.6.
This failed to preserve the original CVS user names.
The reason is that git assumes a null email address for the incoming CVS
user names, so that the git export file has records like this:
author eas 1368997852 +
committer eas 1368997852 +
where eas is my CVS user name, and the null email address is between the
angle brackets.
The fossil importer ignores the first user name, going only for whatever's
in the angle brackets:
if( memcmp(zLine, tagger , 7)==0 || memcmp(zLine, committer ,10)==0
){
sqlite3_int64 secSince1970;
for(i=0; zLine[i] zLine[i]!=''; i++){}
if( zLine[i]==0 ) goto malformed_line;
z = zLine[i+1];
for(i=i+1; zLine[i] zLine[i]!=''; i++){}
if( zLine[i]==0 ) goto malformed_line;
zLine[i] = 0;
fossil_free(gg.zUser);
gg.zUser = fossil_strdup(z);
secSince1970 = 0;
for(i=i+2; fossil_isdigit(zLine[i]); i++){
secSince1970 = secSince1970*10 + zLine[i] - '0';
}
fossil_free(gg.zDate);
gg.zDate = db_text(0, SELECT datetime(%lld, 'unixepoch'),
secSince1970);
gg.zDate[10] = 'T';
I made a quick-and-dirty hack to use the first user name in the case where
the email address is empty. I thought I'd post it in case someone in the
future finds it helpful.
The patch comes with a long list of caveats*, and I'm not suggesting it be
adopted into the fossil trunk at this time. Just posting it for the narrow
purpose of possibly helping other users who are having the same issue
getting their CVS repos into fossil.
--- import.c.orig 2013-07-22 16:24:26.305215527 -0400
+++ import.c2013-07-27 10:49:29.894610274 -0400
@@ -471,21 +471,21 @@
zName[i] = 0;
}
/*
** Read the git-fast-import format from pIn and insert the corresponding
** content into the database.
*/
static void git_fast_import(FILE *pIn){
ImportFile *pFile, *pNew;
- int i, mx;
+ int i, j, k, mx;
char *z;
char *zUuid;
char *zName;
char *zPerm;
char *zFrom;
char *zTo;
char zLine[1000];
gg.xFinish = finish_noop;
while( fgets(zLine, sizeof(zLine), pIn) ){
@@ -569,27 +569,41 @@
}else
if( memcmp(zLine, author , 7)==0 ){
/* No-op */
}else
if( memcmp(zLine, mark , 5)==0 ){
trim_newline(zLine[5]);
fossil_free(gg.zMark);
gg.zMark = fossil_strdup(zLine[5]);
}else
if( memcmp(zLine, tagger , 7)==0 || memcmp(zLine, committer
,10)==0 ){
+ /* Try first to use the email address that is in angle brackets. If
+ ** that is empty, then use the user name that precedes it.
+ */
+ j = (zLine[0]=='t' ? 7 : 10); /* Index the first char of the user
name. */
sqlite3_int64 secSince1970;
for(i=0; zLine[i] zLine[i]!=''; i++){}
if( zLine[i]==0 ) goto malformed_line;
+ k = i-1; /* Index the character just after the user name. */
z = zLine[i+1];
for(i=i+1; zLine[i] zLine[i]!=''; i++){}
if( zLine[i]==0 ) goto malformed_line;
- zLine[i] = 0;
+ if( z[0]==zLine[i] ){
+/* The email address is empty. Use the user name instead of the
+** email address.
+*/
+if( kj ) goto malformed_line;
+z=zLine[j];
+zLine[k] = 0;
+ }else{
+zLine[i] = 0;
+ }
fossil_free(gg.zUser);
gg.zUser = fossil_strdup(z);
secSince1970 = 0;
for(i=i+2; fossil_isdigit(zLine[i]); i++){
secSince1970 = secSince1970*10 + zLine[i] - '0';
}
fossil_free(gg.zDate);
gg.zDate = db_text(0, SELECT datetime(%lld, 'unixepoch'),
secSince1970);
gg.zDate[10] = 'T';
}else
Eric
* This solution is not the right approach overall -- it's probably better
to permit command-line options altering the behavior here. I tested it
only one time, on my one well-formed repo export file, using a different
version of the patch. All my CVS usernames are just lowercase alphabet
characters (with no spaces or funny characters that one of the tools in
question might want to escape or parse differently). I had been using git
and fossil for a total of one calendar day when I made the hack. I have no
idea if git promises to retain their export format. I was born yesterday,
as a fledgling greenhorn tenderfoot newbie fish-face bush leaguer, on the
back of a turnip truck. Etc etc etc. YMMV.
___
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] Ingest CVS repo + cvstrac tickets into fossil?
On Mon, Jul 22, 2013 at 3:05 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 22, 2013 at 9:04 PM, Richard Hipp d...@sqlite.org wrote: The stumbling block is that the ticket text is Wiki, but the format for Fossil Wiki and CVSTrac Wiki is different, which would require a tricky translator. But the ticket system now allows one (IIRC) to change the text type to plain, which could(?) be used to import them in some halfway usable form? Just importing them as plain text would totally be sufficient for my use case -- my brain has a CVSTrac wiki rendering engine in it anyway. :-) Or, frankly, just importing them in whatever fashion would be fine for now -- if the wiki renderings are wrong for some of them, I can just fix them by hand. If later on I'm so burdened that I need to write a translator, I can do that. Basically, your wiki consideration does not seriously concern me -- mostly right is good enough here (just need to preserve severities, headlines etc in the right places). I'm quickly moving in the direction of adopting fossil, and the need to ingest my old tickets is I think the one remaining serious issue. Any recommendations or code you can share before I go start hacking on the sql tables directly (which of course I'd prefer to avoid)? Eric ___ 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 commit is extremely slow
I have a largish repo I ingested from CVS (via git, as I previously
described on this list). I'm using fossil 1.26.
A tiny commit to a single file takes 63 seconds:
[monk:code] $ fossil diff
Index: {snip}/test-file
==
--- {snip}/test-file
+++ {snip}/test-file
@@ -11,5 +11,7 @@
Test6
test7
test8
+
+test9
[monk:code] $ time fossil commit -m Test check-in
New_Version: c46175729e936137f58ef302308d1e95b62e6a61
real1m2.767s
user0m15.090s
sys 0m7.227s
I.e. ~22 seconds of CPU usage, and presumably the rest is on the disk.
The box is pretty old (see below for /proc/cpuinfo), and I know that fossil
is not written to be a speed demon -- but this still seems pretty
ridiculous.
Any way to speed it up for the very common case of making small commits?
How can I gather some more useful data so experts can help me?
Thanks,
Eric
===
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 127
model name : AMD Athlon(tm) Processor LE-1640
stepping: 2
cpu MHz : 1000.000
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp
lm 3dnowext 3dnow up extd_apicid pni cx16 lahf_lm svm extapic cr8_legacy
3dnowprefetch lbrv
bogomips: 1999.50
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
___
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 commit is extremely slow
On Sat, Jul 27, 2013 at 3:16 PM, Eric Rubin-Smith eas@gmail.com wrote: I have a largish repo I ingested from CVS (via git, as I previously described on this list). I'm using fossil 1.26. A tiny commit to a single file takes 63 seconds: [monk:code] $ time fossil commit -m Test check-in New_Version: c46175729e936137f58ef302308d1e95b62e6a61 real1m2.767s user0m15.090s sys 0m7.227s I.e. ~22 seconds of CPU usage, and presumably the rest is on the disk. The box is pretty old (see below for /proc/cpuinfo), and I know that fossil is not written to be a speed demon -- but this still seems pretty ridiculous. That is ridiculous. Most commits take less than a second, even on archaic machines, such as my 15-year-old PPC iBook clocked at 400MHz. How many files are in your check-out? What's the total size of all those files (how big is the checkout)? Is the repository or the check-out on a network filesystem? -- 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] https-login setting
W dniu 2013-07-24 11:22, MaxJarek pisze:
Hi,
My fossil works over http and https. I want to use setting option https-login
but i have trouble.
Documentation says:
Send login credentials using HTTPS instead of HTTP even if the login page request
came via HTTP
but this don't working for me.
Fossil don't force https login. Any hints?
maxjarek
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
I still can't find good way to configure this feature. For me it is bug.
I found fragment in login.c :
...
if( g.sslNotAvailable==0
memcmp(g.zBaseURL,https:,6)!=0
db_get_boolean(https-login,0)
){
char *zSSL = mprintf(https:%s, g.zBaseURL[5]);
@ if( form.u.value!=anonymous ){
@ form.action = %h(zSSL)/login;
@ }
}
@ }
...
I think the g.sslNotAvailable in fossil server mode is always 1.
This is the reason why https-login setting don't work.
Can I ask to look at the problem?
jarek
___
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 commit is extremely slow
On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp d...@sqlite.org wrote: That is ridiculous. Most commits take less than a second, even on archaic machines, such as my 15-year-old PPC iBook clocked at 400MHz. How many files are in your check-out? [monk:repo.fossil] $ find .|wc -l 8095 What's the total size of all those files (how big is the checkout)? [monk:repo.fossil] $ du -sch . 392M. 392Mtotal Is the repository or the check-out on a network filesystem? No and no. Eric ___ 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 commit is extremely slow
If Windows, add fossil.exe to the excluded process list of your antivirus app. On Sat, Jul 27, 2013 at 3:41 PM, Eric Rubin-Smith eas@gmail.com wrote: On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp d...@sqlite.org wrote: That is ridiculous. Most commits take less than a second, even on archaic machines, such as my 15-year-old PPC iBook clocked at 400MHz. How many files are in your check-out? [monk:repo.fossil] $ find .|wc -l 8095 What's the total size of all those files (how big is the checkout)? [monk:repo.fossil] $ du -sch . 392M. 392Mtotal Is the repository or the check-out on a network filesystem? No and no. Eric ___ 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 commit is extremely slow
On Sat, Jul 27, 2013 at 3:41 PM, Eric Rubin-Smith eas@gmail.com wrote: On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp d...@sqlite.org wrote: What's the total size of all those files (how big is the checkout)? [monk:repo.fossil] $ du -sch . 392M. 392Mtotal That would be the culprit. As one of several self-checks (see http://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki), Fossil always computes an MD5 checksum over the entire check-out and compares that to the content being checked in, to make sure they are identical. With a 392MB checkout on an older machine, that might easily take a minute. The Fossil repositories for Fossil itself, and for SQLite are just 14MB and 22MB, respectively. And I do most of my work on a fast machine, so I never notice the extra commit-time needed for this self-check. I think you can turn off this safety-check using: fossil setting repo-cksum off Please try that, and let us know whether or not it solves your 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 commit is extremely slow
On Sat, Jul 27, 2013 at 4:15 PM, Richard Hipp d...@sqlite.org wrote: On Sat, Jul 27, 2013 at 3:41 PM, Eric Rubin-Smith eas@gmail.comwrote: On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp d...@sqlite.org wrote: What's the total size of all those files (how big is the checkout)? [monk:repo.fossil] $ du -sch . 392M. 392Mtotal That would be the culprit. As one of several self-checks (see http://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki), Fossil always computes an MD5 checksum over the entire check-out and compares that to the content being checked in, to make sure they are identical. With a 392MB checkout on an older machine, that might easily take a minute. I tested this basic claim and do not believe it holds: [monk:~] $ head -c $(echo 392*1024*1024|bc) /dev/zero foo [monk:~] $ du -sch foo 392Mfoo 392Mtotal [monk:~] $ time md5sum foo c6d8f8fc5c75fd6ecceb4edf42f3ac4d foo real0m1.324s user0m0.998s sys 0m0.247s So just over a second to calculate that hash on the same box. I retried this after dropping kernel caches to test whether it's the disk, and it still only took 3.6 seconds to calculate the hash. Of course, that's just the time it takes to calculate the hash. Obviously it does not include the time spent concatenating the world together to send to your MD5 function. Perhaps there's a super-linear algorithm in that concatenation stuff? Turning off repo-cksum* **did* address the issue, at least by an order of magnitude: [monk:code] $ fossil setting repo-cksum off [monk:code] $ time fossil commit -m test commit New_Version: 4d3b92dca8a617d6004bbe4e9c158fc11882720d real0m7.365s user0m0.627s sys 0m0.398s Does this leave any serious gaps in fault-tolerance? The new performance is acceptable, though I'm still happy to keep digging around if you're still curious (either about what was taking so long, or about what is still taking 7 seconds, or both). Thanks Richard. Eric ___ 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 commit is extremely slow
On Sat, Jul 27, 2013 at 10:31 PM, Eric Rubin-Smith eas@gmail.comwrote: [monk:code] $ fossil setting repo-cksum off FYI: if you want that setting used globally by default for your repos, add the -global flag. Otherwise it will apply on to that repo. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 commit is extremely slow
Thus said Eric Rubin-Smith on Sat, 27 Jul 2013 16:31:46 -0400:
I tested this basic claim and do not believe it holds:
[monk:~] $ head -c $(echo 392*1024*1024|bc) /dev/zero foo
[monk:~] $ du -sch foo
392Mfoo
392Mtotal
[monk:~] $ time md5sum foo
c6d8f8fc5c75fd6ecceb4edf42f3ac4d foo
real0m1.324s
user0m0.998s
sys 0m0.247s
I believe this test is slightly flawed. You have 8095 files and
directories for a total of 392M. This is not at all the same as 1 file
that totals 392M. So your test doesn't account for the distribution of
the data on the disk and the file system slowness that could result
therefrom.
A better comparison would be:
time find . -type f -exec md5sum {} \;
Andy
--
TAI64 timestamp: 400051f43494
___
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 commit is extremely slow
On Sat, Jul 27, 2013 at 4:58 PM, Andy Bradford
amb-sendok-1377550706.oeilkncbciakkppah...@bradfords.org wrote:
Thus said Eric Rubin-Smith on Sat, 27 Jul 2013 16:31:46 -0400:
I tested this basic claim and do not believe it holds:
[monk:~] $ head -c $(echo 392*1024*1024|bc) /dev/zero foo
[monk:~] $ du -sch foo
392Mfoo
392Mtotal
[monk:~] $ time md5sum foo
c6d8f8fc5c75fd6ecceb4edf42f3ac4d foo
real0m1.324s
user0m0.998s
sys 0m0.247s
I believe this test is slightly flawed. You have 8095 files and
directories for a total of 392M. This is not at all the same as 1 file
that totals 392M. So your test doesn't account for the distribution of
the data on the disk and the file system slowness that could result
therefrom.
Good point! Not to mention duplicated syscall overhead etc. I ran a riff
on your idea and got a very different result:
[monk:repo.fossil] $ time find . -type f -exec cat {} \; | md5sum -
3abe8f411181a328c7b64946ff6a9c7a -
real0m37.631s
user0m2.973s
sys 0m11.543s
As you predicted, most of that time is spent on disk I/O, not e.g. in
forking 'cat'. So that explains over half of the run-time for my fossil
command.
For the other half, I ran fossil under callgrind and found that at least
44% of its instruction reads were inside zlib, and at least 34% were spent
updating the MD5 sum:
Ir
41,797,779,918 PROGRAM TOTALS
Ir file:function
18,101,410,264 /usr/src/debug/zlib-1.2.5/inflate.c:inflate (55531x)
[/lib64/libz.so.1.2.5]
18,101,410,264 * /usr/src/debug/zlib-1.2.5/inffast.c:inflate_fast
[/lib64/libz.so.1.2.5]
13,824,797,833 /home/eas/Fossil-c9cb6e72932fefbe/./src/md5.c:MD5Update
(24296657x) [/usr/local/bin/fossil-1.26-eas-built]
3,983 /home/eas/Fossil-c9cb6e72932fefbe/./src/md5.c:MD5Final
(7x) [/usr/local/bin/fossil-1.26-eas-built]
13,824,801,816 *
/home/eas/Fossil-c9cb6e72932fefbe/./src/md5.c:MD5Transform
[/usr/local/bin/fossil-1.26-eas-built]
(and those are just the top two functions).
All that uncompressing seems to come from blob_uncompress. So I guess the
only remaining question is whether all those blob uncompresses are really
necessary. I assume yes -- and in any case I have my answers. :-)
Thanks again.
Eric
___
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] https-login setting
Thus said MaxJarek on Wed, 24 Jul 2013 11:22:52 +0200: Fossil don't force https login. Any hints? Try setting https-login in your global config prior to cloning: fossil settings https-login on Andy -- TAI64 timestamp: 400051f445b1 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] merging and file names: help text is wrong and conflicts are not reported
From 'fossil help merge': === Only file content is merged. The result continues to use the file and directory names from the current checkout even if those names might have been changed in the branch being merged in. === This struck me as very odd. If the file name only changed on the branch being merged in (called M in the code) since the nearest common ancestor, then the file name on M should be chosen. So I did some digging. It turns out that this documentation is not correct. The code in merge.c and my own hand-testing confirm that the behavior is what you would expect. So I think the help text needs an update. And, BTW, the fact that renaming conflicts are not raised to the user (fossil silently chooses the target version's name) should probably be considered a serious bug. I skimmed through open tickets on the ticket tracker and didn't find anything open for that. I noticed a related ticket here[1], however, which I think is no longer valid and can be closed. Eric [1] http://www.fossil-scm.org/index.html/tktview?name=67176c3aa4 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
