Re: [fossil-users] question about parms and ownership of repo vs current/parent dir
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 638 bytes sent, 319 bytes received
I get a different error entirely:
# fossil sync new.fossil -R clone.fossil
server sends error:
SQLITE_CANTOPEN: cannot open file at line 29670 of [d018a34a05]
SQLITE_CANTOPEN: os_unix.c:29670: (2) open(/new.fossil-journal) - No such file
or directory
SQLITE_CANTOPEN: statement aborts at 22: [INSERT INTO
config(name,value,mtime)VALUES('baseurl:http://',1,now())]
Database Error
unable to open database file: {INSERT INTO
config(name,value,mtime)VALUES('baseurl:http://',1,now())}
If you have recently updated your fossil executable, you might
need to run fossil all rebuild to bring the repository
schemas up to date.
Sync finished with 381 bytes sent, 835 bytes received
The path above in the open(/new.fossil-journal) does seem like a
chroot/user permission issue so perhaps my original suspicions were
correct. I didn't think a file sync would behave the same as others and
at first glance in the code, it doesn't appear to, however, it
definitely looks like this might be the case. I'll see if I can dig up
the actual cause.
Andy
--
TAI64 timestamp: 4000538820a8
___
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] question about parms and ownership of repo vs current/parent dir
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200: Can anyone tell what happens under the hood here..? Bingo: http://www.fossil-scm.org/index.html/artifact/d1aef141c961172a1a32f619f339c641cdeaa674?ln=259,268 So it does indeed call ``fossil http'' which will cause fossil to chroot and drop privileges depending on the owner of the file. I see from your email that the permissions on /tmp/ftmp are 755 which means only root will be able to create/modify files in that directory: root@main:/tmp/ftmp# ls -ld * . drwxr-xr-x 2 root wheel 512 May 29 15:33 . -rw-r--r-- 1 root wheel 3435520 May 29 15:33 f_f -rw-r--r-- 1 root wheel 3592192 May 29 15:33 r_w Andy -- TAI64 timestamp: 400053882443 ___ 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] question about parms and ownership of repo vs current/parent dir
On 30 May 2014 08:09, Andy Bradford
amb-sendok-1404022150.hdbpagcekdcgljghk...@bradfords.org wrote:
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 638 bytes sent, 319 bytes received
I get a different error entirely:
...
Thank you for testing. This looks almost exactly what I got here when
syncing, when the repos were not yet in sync.
I didn't post this error, because after getting the repos in sync
(eventually by changing permissions/ownership, then syncing), there
was still an error, which I posted. I thought the 'in sync' situation
was a nicer minimal testcase - I probably should have mentioned this
right at the start.
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] question about parms and ownership of repo vs current/parent dir
On 30 May 2014 08:24, Andy Bradford amb-sendok-1404023072.eeipjlgjbincchjbb...@bradfords.org wrote: Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200: Can anyone tell what happens under the hood here..? Bingo: http://www.fossil-scm.org/index.html/artifact/d1aef141c961172a1a32f619f339c641cdeaa674?ln=259,268 So it does indeed call ``fossil http'' which will cause fossil to chroot and drop privileges depending on the owner of the file. I see from your email that the permissions on /tmp/ftmp are 755 which means only root will be able to create/modify files in that directory: Ok, thanks for analysis. It looks like this (thread) explains everything I saw here. 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] libfossil minor milestone: Raspberry Pi
On Fri, May 30, 2014 at 3:36 AM, Warren Young war...@etr-usa.com wrote: PowerPC does some strange things with char, too. You might have fixed that in passing. Very possibly. The bug was that i assumed (despite knowing better, deep down) that (char) is signed, but C does not specify its signedness. i had used (1, 0, -1) as yes/no/maybe logic in several places, and that resulted in (1, 0, 255) on the Pi (where char is unsigned). The bug luckily revealed itself (in other code) in such a way that it was obvious what was happening, but then i had to go clean up 3 other projects where i had done the same thing :/. As a comparison of runtime speeds, here's the results of the core sanity tests on my workstation How much work does this test do compared to normal user operations? Say, a normal checkin, or a pull of the /tree URL from fossil server? Excellent question: the timing i showed is all of the sanity tests, which is almost (but not quite) at least one run of all of the basic features, including creating a checkin, extracting all files from the current version, and lots of other stuff which is, in practice, never run together in the same execution. i.e. it's doing a lot more than any single command does. A Pi really isn't all that slow, in historical terms. It's only about 10 years behind the times, in terms of raw horsepower. Raspbian comes with Mathematica after all, and it runs reasonably well under X. i suspect (haven't checked) that a pain point for fossil/libfossil here is (or will be) memory usage. The Pi is hard-wired for 512MB and Fossil has linear memory costs (sometimes on the size of the largest file, sometimes on the combination of files and their sizes). For example, the sanity check creates a ZIP file from the current version. That happens all in memory, and extracting the versions of each file is a RAM-intensive operation. It's very possible (haven't checked) that the Pi is swapping like mad there. But it runs, and that's the main thing :). The Pi is not fast, but it's really, really, really quiet (no noise whatsoever). Yeah, plug the headphone port into a power amplifier and get back to me about no noise whatsoever. ;) lol. Haven't tried that - i use my tablet for audio/video more often than not. [2]: It costs less in winter where the heat produced reduces the heating bill, but doubles in summer where every watt produced has to be removed by the AC system. i'm in southern Germany, and have yet to see a house here which has AC ;) (even most offices don't have it). My current laptop is basically enough to heat a whole room, and in fact it does save me heating costs (i use it to warm up pizza slices sometime!). Contrariwise, in summer it can get a bit too warm :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Autosync retry?
Le 29 mai 2014 16:10, Stephan Beal sgb...@googlemail.com a écrit : Wasn't even aware of pull-only until earlier today. snip Same for me, I always use autosync=1 together with the dont-push=1 setting for that. Look like an option got added by someone that didn't know about the other. -- Martin G. ___ 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] Autosync retry?
On Fri, May 30, 2014 at 11:55 AM, Martin Gagnon eme...@gmail.com wrote: Same for me, I always use autosync=1 together with the dont-push=1 setting for that. Look like an option got added by someone that didn't know about the other. LOL - wasn't aware of dont-push, either ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] use of 'fossil close'
Hello,
a related issue has come up here at least one: is there any real use
for 'fossil close' of a repo?
I have only recently started using 'fossil all', and notice that
'fossil all ls -c' (i.e. list checkouts) still show checkout-roots
that have been closed.
I always used the 'close' command, but now I am assuming it's pretty
safe to check for changes ('fossil changes'), then check for extras
('fossil extra'), and then simply to delete the root of the checkout.
Is that correct?
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 clone on localhost
Hello, I asked a while ago about apparent slowness when cloning a repo on the localhost (using 'http://localhost/...', because a script happened to work like that). Could anyone give an example of when it makes sense to clone a repo on localhost at all, assuming it ever makes sense..? (I am currently cleaning up various scripts and dirs here, and a lot of sillyness shows up :) 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] use of 'fossil close'
On Fri, May 30, 2014 at 2:24 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
a related issue has come up here at least one: is there any real use
for 'fossil close' of a repo?
Rarely. i can count on one hand the number of times i've used it since
2008. You can get the same effect with:
rm -f .fslckout _FOSSIL_
Well, same effect except for...
I have only recently started using 'fossil all', and notice that
'fossil all ls -c' (i.e. list checkouts) still show checkout-roots
that have been closed.
That's likely a misinteraction with the all setup and close. When
fossil opens a repo db, it automatically records it in the global config db
for 'all' purposes. The close command should (but apparently doesn't?)
remove that file from the 'all' list. i'll take a look at it this evening.
I always used the 'close' command, but now I am assuming it's pretty
safe to check for changes ('fossil changes'), then check for extras
('fossil extra'), and then simply to delete the root of the checkout.
Is that correct?
Sounds right to me. Close might (don't have a repo to try it with at the
moment) also warn if you have uncommitted changes?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
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 clone on localhost
On Fri, May 30, 2014 at 2:28 PM, Michai Ramakers m.ramak...@gmail.com wrote: Could anyone give an example of when it makes sense to clone a repo on localhost at all, assuming it ever makes sense..? (I am currently i can only think of one (small) reason: to avoid having to know the path to the repo file. Functionally, it will be equivalent to cloning from a local copy of the repo. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] use of 'fossil close'
On 30 May 2014 14:29, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 30, 2014 at 2:24 PM, Michai Ramakers m.ramak...@gmail.com wrote: I have only recently started using 'fossil all', and notice that 'fossil all ls -c' (i.e. list checkouts) still show checkout-roots that have been closed. That's likely a misinteraction with the all setup and close. When fossil opens a repo db, it automatically records it in the global config db for 'all' purposes. The close command should (but apparently doesn't?) remove that file from the 'all' list. i'll take a look at it this evening. Thanks in advance. I guess 'all' makes a lot of sense if the workflow cooperates; if it's not a bug, I'd be happy to hear how other people use it. Sounds right to me. Close might (don't have a repo to try it with at the moment) also warn if you have uncommitted changes? Right, it does. 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 clone on localhost
On 30 May 2014 14:28, Michai Ramakers m.ramak...@gmail.com wrote: Could anyone give an example of when it makes sense to clone a repo on localhost at all, assuming it ever makes sense..? (I am currently cleaning up various scripts and dirs here, and a lot of sillyness shows up :) ok, found another small reason having to do with permissions, perhaps related with yesterday's thread about permissions. Without looking, I guess tempfiles (journal-related?) are being written in the repo-dir, is that so? (Repo-dir didn't have write-access for me yet; I was assuming there were only writes/reads to an already existing file - the repo - in that dir, for which one doesn't need write-perms in the dir.) Anyway, that's circumvented easily. I'll have a single repo per project per machine, which seems simplest. 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 clone on localhost
On Fri, May 30, 2014 at 3:02 PM, Michai Ramakers m.ramak...@gmail.com wrote: ok, found another small reason having to do with permissions, perhaps related with yesterday's thread about permissions. Without looking, I guess tempfiles (journal-related?) are being written in the repo-dir, is that so? Good point. Temp files are created wherever sqlite3 decides to create them. The journal file definitely lives in the repo dir, at least when run via CGI. In server mode, the journal/temp files need only be writable by the server process user (which will be the owner of the repo db if the server is started as root). Anyway, that's circumvented easily. I'll have a single repo per project per machine, which seems simplest. Not sure this really helps, but on my main hoster i put all my repos under ~/fossil/., and those files have 0600 permissions. The CGI processes which access them are (thankfully) run as my account (as opposed to as the apache/www user), so they then have access to the repo dbs. The dbs are kept outside of the wwwroot so that nobody can copy them directly via HTTP (that can also be controlled via .htaccess, but that requires yet another config setting file). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Autosync retry?
On Fri, May 30, 2014 at 5:55 AM, Martin Gagnon eme...@gmail.com wrote: Le 29 mai 2014 16:10, Stephan Beal sgb...@googlemail.com a écrit : Wasn't even aware of pull-only until earlier today. snip Same for me, I always use autosync=1 together with the dont-push=1 setting for that. Look like an option got added by someone that didn't know about the other. As I recall, the 2 options have slightly different affects. pull-only only affects auto sync, while dont-push affects both manual and auto sync. A manual push will, of course, still push. ___ 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] Autosync retry?
Thus said Ron Wilson on Fri, 30 May 2014 09:42:44 -0400: As I recall, the 2 options have slightly different affects. pull-only only affects auto sync, while dont-push affects both manual and auto sync. A manual push will, of course, still push. ``pull-only'' pertains only to the autosync code (used by checkin and update), however, ``dont-push'' also affects autosync. It does appear, however, that ``push-only'' also affects manual pushes, so they seem to have different purposes: http://www.fossil-scm.org/index.html/artifact/912d6a207a3e070b3b2c1c46d2395ff3e4ec76c2?ln=203,205 It also affect any client_sync operation in general: http://www.fossil-scm.org/index.html/artifact/37f2afbbd186bf5cef90c57b7fa1acd7097977cd?ln=1418 Andy -- TAI64 timestamp: 400053889b85 ___ 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] use of 'fossil close'
On Fri, May 30, 2014 at 2:29 PM, Stephan Beal sgb...@googlemail.com wrote: That's likely a misinteraction with the all setup and close. When fossil opens a repo db, it automatically records it in the global config db for 'all' purposes. The close command should (but apparently doesn't?) remove that file from the 'all' list. i'll take a look at it this evening. Hi Michai! Can i convince you to please try this out this branch: http://fossil-scm.org/index.html/timeline?r=close-cleanup-configunhide :-? indeed, the close command was not removing its entry from the global config. Getting it to do so was trickier than i would have thought because the config db isn't always opened and it might not be writable. The above works for me, but i consolidated the repo- and global-level removal of this config key into one step, and i'm not 100% certain it is side-effect-free, so i have put it in a separate branch for the time being. e.g. it no longer checks whether the repo db is writeable (because the routine which consolidates the removal of the config key from both config dbs does not do that). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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 clone on localhost
On Fri, May 30, 2014 at 8:30 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 30, 2014 at 2:28 PM, Michai Ramakers m.ramak...@gmail.com wrote: Could anyone give an example of when it makes sense to clone a repo on localhost at all, assuming it ever makes sense..? (I am currently i can only think of one (small) reason: to avoid having to know the path to the repo file. Functionally, it will be equivalent to cloning from a local copy of the repo. Related to that, git and Mercurial make their repositories an integral part of a workspace, so users coming from git and Mercurial (and maybe others) might be more comfortable cloning repo+workspace rather than having multiple workspaces for a single repo. ___ 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] libfossil minor milestone: Raspberry Pi
On Fri, May 30, 2014 at 10:20 AM, Stephan Beal sgb...@googlemail.com
wrote:
On Fri, May 30, 2014 at 3:36 AM, Warren Young war...@etr-usa.com wrote:
How much work does this test do compared to normal user operations? Say,
a normal checkin, or a pull of the /tree URL from fossil server?
Excellent question: the timing i showed is all of the sanity tests,
which is almost (but not quite) at least one run of all of the basic
features, including creating a checkin, extracting all files from the
current version, and lots of other stuff which is, in practice, never run
together in the same execution. i.e. it's doing a lot more than any single
command does.
Okay, i was curious myself about this, so here are some rough comparisons
for some basic single operations:
Notes:
a) pi is using an external USB 2.0 drive here because compiling anything on
a SD card is just too pokey.
b) These f-xyz calls are the libfossil CLI tools:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/wiki?name=f-tools
- f-acat rid:1
pi: 0.34s
laptop: 0.17s
- f-resolve trunk
pi: 0.77s
laptop: 0.13s
- f-zip tip foo.zip
pi: 29.99s (!!!)
laptop: 1.81s
That one is very RAM-hungry ('massif' says peak RAM of 11MB, total
allocated 175MB)
- f-vdiff current prev
pi: 0.29s
laptop: 0.16s
So, overall, the performance is actually much better than i might expect,
but some operations (those which need lots of memory) are likely to cause
swapping, which will slow it down notably.
Today i discovered the ODROID-U3 platform, kind of like a super-pi, and
ordered one to play with. i'll post some numbers once that arrives (no idea
when that will be).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
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] committing wiki pages changes format parser
On Wed, May 14, 2014 at 5:55 PM, Stephan Beal sgb...@googlemail.com wrote: Would this strategy server your purpose: - add a (-format FORMAT) option to (wiki commit). - if no format is specified, use the format from the prior version (if there is one), defaulting to fossil-wiki if no prior version is set or the prior version has no explicit format. Hi, Chad! i've gone ahead and merged that into the trunk, but i renamed the flag to --mimetype|-M, instead of --format (it turns out i had a semantic conflict with format in /json/wiki, where format is used for another purpose). So: fossil wiki commit PageName InputFile --mimetype text/x-markdown if you leave of -mimetype, it will default to whatever the previous version of the page had. Have fun! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] working checkout does not match what would have ended up in the repository
Hello, some weirdness I have not seen before: michai@main:~/proj/081/adm$ f changes ADDED time_spent.txt ADDED ../comm/20140530_sent_to_ec/indicator-B_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-B_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator-Edge_Cuts.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator.drl ADDED ../sch/indicator-B_Cu.pho ADDED ../sch/indicator-B_Mask.pho ADDED ../sch/indicator-Edge_Cuts.pho ADDED ../sch/indicator-F_Cu.pho ADDED ../sch/indicator-F_Mask.pho ADDED ../sch/indicator-cache.lib ADDED ../sch/indicator.bak ADDED ../sch/indicator.cmp ADDED ../sch/indicator.drl ADDED ../sch/indicator.kicad_pcb ADDED ../sch/indicator.kicad_pcb-bak ADDED ../sch/indicator.net ADDED ../sch/indicator.pro ADDED ../sch/indicator.sch michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e The file 'adm/time_spent.txt' is 163 bytes. (Googling for the error-message turned up a previous post, where file size was the cause.) Most if not all of the other files give the same error-message. Any idea how to debug this? I am using fossil version 1.29 [87130593e4] 2014-05-26. 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] working checkout does not match what would have ended up in the repository
and... michai@main:~/proj/081$ f timeline +++ no more data (0) +++ This is a brand new repo; indeed there are no checkins. Michai On 30 May 2014 21:06, Michai Ramakers m.ramak...@gmail.com wrote: Hello, some weirdness I have not seen before: michai@main:~/proj/081/adm$ f changes ADDED time_spent.txt ADDED ../comm/20140530_sent_to_ec/indicator-B_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-B_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator-Edge_Cuts.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator.drl ADDED ../sch/indicator-B_Cu.pho ADDED ../sch/indicator-B_Mask.pho ADDED ../sch/indicator-Edge_Cuts.pho ADDED ../sch/indicator-F_Cu.pho ADDED ../sch/indicator-F_Mask.pho ADDED ../sch/indicator-cache.lib ADDED ../sch/indicator.bak ADDED ../sch/indicator.cmp ADDED ../sch/indicator.drl ADDED ../sch/indicator.kicad_pcb ADDED ../sch/indicator.kicad_pcb-bak ADDED ../sch/indicator.net ADDED ../sch/indicator.pro ADDED ../sch/indicator.sch michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e The file 'adm/time_spent.txt' is 163 bytes. (Googling for the error-message turned up a previous post, where file size was the cause.) Most if not all of the other files give the same error-message. Any idea how to debug this? I am using fossil version 1.29 [87130593e4] 2014-05-26. 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] working checkout does not match what would have ended up in the repository
Is the offending file a symbolic link? On Fri, May 30, 2014 at 3:11 PM, Michai Ramakers m.ramak...@gmail.com wrote: and... michai@main:~/proj/081$ f timeline +++ no more data (0) +++ This is a brand new repo; indeed there are no checkins. Michai On 30 May 2014 21:06, Michai Ramakers m.ramak...@gmail.com wrote: Hello, some weirdness I have not seen before: michai@main:~/proj/081/adm$ f changes ADDED time_spent.txt ADDED ../comm/20140530_sent_to_ec/indicator-B_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-B_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator-Edge_Cuts.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator.drl ADDED ../sch/indicator-B_Cu.pho ADDED ../sch/indicator-B_Mask.pho ADDED ../sch/indicator-Edge_Cuts.pho ADDED ../sch/indicator-F_Cu.pho ADDED ../sch/indicator-F_Mask.pho ADDED ../sch/indicator-cache.lib ADDED ../sch/indicator.bak ADDED ../sch/indicator.cmp ADDED ../sch/indicator.drl ADDED ../sch/indicator.kicad_pcb ADDED ../sch/indicator.kicad_pcb-bak ADDED ../sch/indicator.net ADDED ../sch/indicator.pro ADDED ../sch/indicator.sch michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e The file 'adm/time_spent.txt' is 163 bytes. (Googling for the error-message turned up a previous post, where file size was the cause.) Most if not all of the other files give the same error-message. Any idea how to debug this? I am using fossil version 1.29 [87130593e4] 2014-05-26. 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
Re: [fossil-users] working checkout does not match what would have ended up in the repository
On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? no: -rw-r--r-- 1 michai users 163 May 30 20:42 time_spent.txt nor are there any symlinks in the path leading to the file or repo. If interested: the repo is about 53 kB; I could mail it for analysis. 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] working checkout does not match what would have ended up in the repository
On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? I don't think it's the contents of this or the other files causing this: michai@main:~/proj/081$ echo kiwi kiwi michai@main:~/proj/081$ f add kiwi ADDED kiwi michai@main:~/proj/081$ f ci -m 'fossil bughunt test' kiwi New_Version: 5cc2d83c0b2621e0c5fc4ebd72caf8dd7c0d3b5e working checkout does not match what would have ended up in the repository: 3e24a53b4cca8ff8caa51c21d04c7705 versus 7bff63ee19686815f2ccd4a072a0c4be 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] working checkout does not match what would have ended up in the repository
On Fri, May 30, 2014 at 3:23 PM, Michai Ramakers m.ramak...@gmail.com wrote: On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? I don't think it's the contents of this or the other files causing this: michai@main:~/proj/081$ echo kiwi kiwi michai@main:~/proj/081$ f add kiwi ADDED kiwi michai@main:~/proj/081$ f ci -m 'fossil bughunt test' kiwi New_Version: 5cc2d83c0b2621e0c5fc4ebd72caf8dd7c0d3b5e working checkout does not match what would have ended up in the repository: 3e24a53b4cca8ff8caa51c21d04c7705 versus 7bff63ee19686815f2ccd4a072a0c4be The proximal cause of the error message is the pre-commit sanity checks that Fossil runs on each check-in. (See http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki for details.) Fossil is looking at the files it is about to commit, and comparing them to the files on disk, and seeing that they do not match. Hence, it aborts the check-in. I do not know what is the root cause of this mismatch, however. Could it be that some other process or thread is changing files in your check-out in the background, as you are trying to commit? -- 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] libfossil minor milestone: Raspberry Pi
On 5/30/2014 11:23, Stephan Beal wrote: a) pi is using an external USB 2.0 drive here because compiling anything on a SD card is just too pokey. Rotating media or SSD? Did you use the same external HDD on the laptop, or did it have an unfair advantage in its internal drive? b) These f-xyz calls are the libfossil CLI tools: I saw the caveat about networking on your f-commit tool, but does it work with local repositories? If so, would you try that test, too? I speculate that f-acat and f-commit model a huge chunk of everyday command line Fossil use. I hope you were doing all of these tests locally, and not introducing the network as a confounding factor. The RPi NIC is only 100 Mbit/s. Even if you don't saturate it, packet latency will still be higher than GigE. - f-acat rid:1 pi: 0.34s laptop: 0.17s Interesting, only about 2x slower. Not even that much, if I'm right in guessing that you have some confounding variables. ___ 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] working checkout does not match what would have ended up in the repository
On 30 May 2014 21:27, Richard Hipp d...@sqlite.org wrote: The proximal cause of the error message is the pre-commit sanity checks that Fossil runs on each check-in. (See http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki for details.) Fossil is looking at the files it is about to commit, and comparing them to the files on disk, and seeing that they do not match. Hence, it aborts the check-in. I do not know what is the root cause of this mismatch, however. Could it be that some other process or thread is changing files in your check-out in the background, as you are trying to commit? I checked, but there doesn't seem to be anything. If I open in another dir a copy of this repo and try to add a new dummy-file, everything Just Works(tm). I can leave this as-is for a little while, in case there are any other ideas. 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] libfossil minor milestone: Raspberry Pi
On Fri, May 30, 2014 at 9:33 PM, Warren Young war...@etr-usa.com wrote: On 5/30/2014 11:23, Stephan Beal wrote: a) pi is using an external USB 2.0 drive here because compiling anything on a SD card is just too pokey. Rotating media or SSD? Plain old cheap spinning disk. i don't want to migrate to SSD until i can migrate all my machines, because i'm afraid i'll get spoiled by the speed difference and then resent all of my spinning disk (i've got 7 or 8 external USB drives laying around here). Did you use the same external HDD on the laptop, or did it have an unfair advantage in its internal drive? The laptop used its internal drive, which is most certainly faster than USB2 and almost certainly has a much larger cache (it's a relatively high-end laptop intended for software development). The laptop also (with 8GB RAM) doesn't ever need to swap, whereas the Pi will now and again. So, of course this is an apples/oranges (or raspberries!) comparison. b) These f-xyz calls are the libfossil CLI tools: I saw the caveat about networking on your f-commit tool, but does it work with local repositories? If so, would you try that test, too? I speculate that f-acat and f-commit model a huge chunk of everyday command line Fossil use. Yes, it does work fine on local repos, with one minor caveat: the current leaf is (for reasons i don't understand) not getting recalculated properly. After a checkin, the current leaf is always (in the timeline) marked as the previous version. A rebuild fixes it, which means that the metadata is right, but that something is missing in the calculation of the leaf. It's solely a cosmetic problem, but an annoying one nonetheless. FWIW, i use it regularly for doing libf checkins. I hope you were doing all of these tests locally, and not introducing the network as a confounding factor. The RPi NIC is only 100 Mbit/s. Even if you don't saturate it, packet latency will still be higher than GigE. The RPI connection is over ethernet/ssh, but the console output for these simple tests is not enough to affect the test speed. The drive is connected directly to the Pi - i would never in my life use a fossil repo on an NFS mount. - f-acat rid:1 pi: 0.34s laptop: 0.17s Interesting, only about 2x slower. Not even that much, if I'm right in guessing that you have some confounding variables. i found that one particularly interesting. My assumption is that the startup overhead (opening the repo db) is the major factor there, but i'm not interested enough in it to explore it further ;). So long as it runs, i'm happy. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] working checkout does not match what would have ended up in the repository
On Fri, May 30, 2014 at 9:11 PM, Michai Ramakers m.ramak...@gmail.com wrote: michai@main:~/proj/081$ f timeline +++ no more data (0) +++ This is a brand new repo; indeed there are no checkins. *cough* this looks _exactly_ like a bug we had recently involving the rid 0 (no checkins) case. i don't remember the details and i'm about to head off to bed. Maybe someone who remembers this happening about 2-3 weeks back can look into it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] working checkout does not match what would have ended up in the repository
On Fri, May 30, 2014 at 9:23 PM, Michai Ramakers m.ramak...@gmail.com wrote: On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? I don't think it's the contents of this or the other files causing this: michai@main:~/proj/081$ echo kiwi kiwi michai@main:~/proj/081$ f add kiwi ADDED kiwi michai@main:~/proj/081$ f ci -m 'fossil bughunt test' kiwi New_Version: 5cc2d83c0b2621e0c5fc4ebd72caf8dd7c0d3b5e working checkout does not match what would have ended up in the Is this repo _completely_ empty (no initial checkin)? If so, please recreate it with an initial empty checkin and i'll bet my left leg the problem goes away. If it is _not_ a completely empty repo then i'm at a loss. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] working checkout does not match what would have ended up in the repository
On 30 May 2014 22:25, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 30, 2014 at 10:15 PM, Stephan Beal sgb...@googlemail.com wrote: Is this repo _completely_ empty (no initial checkin)? If so, please recreate it with an initial empty checkin and i'll bet my left leg the problem goes away. If it is _not_ a completely empty repo then i'm at a loss. H. It seems fossil no longer has an option to create the initial checkin, and i can't figure out how to create one without libfossil: ... I have been reading libfossil progress here, but haven't actually used it yet or played with it. What you say might just be very related - come to think of it, I think this is the 1st repo I create after updating to a recent fossil binary. (I remember seeing the initial checkin changes in the timeline - I think all other repos here are created with older fossil-binaries.) That is worth checking out, thank 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] use of 'fossil close'
On 30 May 2014 18:43, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 30, 2014 at 2:29 PM, Stephan Beal sgb...@googlemail.com wrote: That's likely a misinteraction with the all setup and close. When fossil opens a repo db, it automatically records it in the global config db for 'all' purposes. The close command should (but apparently doesn't?) remove that file from the 'all' list. i'll take a look at it this evening. Hi Michai! Can i convince you to please try this out this branch: ... Of course; earlier this evening I had to finish another thing, and now the wife demands attention... I'll test this either later this evening or else tomorrow morning. 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] use of 'fossil close'
No hurry - i won't be back on the pc until tomorrow evening. The wife's attention takes priority, in any case! If at first I don't succeed... my wife will never let me forget it. (recently heard in a video game) (sent from a mobile device - please excuse brevity, typos, and top-posting) - stephan beal http://wanderinghorse.net On May 30, 2014 10:56 PM, Michai Ramakers m.ramak...@gmail.com wrote: On 30 May 2014 18:43, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 30, 2014 at 2:29 PM, Stephan Beal sgb...@googlemail.com wrote: That's likely a misinteraction with the all setup and close. When fossil opens a repo db, it automatically records it in the global config db for 'all' purposes. The close command should (but apparently doesn't?) remove that file from the 'all' list. i'll take a look at it this evening. Hi Michai! Can i convince you to please try this out this branch: ... Of course; earlier this evening I had to finish another thing, and now the wife demands attention... I'll test this either later this evening or else tomorrow morning. 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] working checkout does not match what would have ended up in the repository
Thus said Michai Ramakers on Fri, 30 May 2014 21:06:36 +0200: michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e Looks like this is due to the recent addition of the empty initial checkin in [cac91b6cd17ab746]: $ fossil bisect bad bisect complete 2 BAD 2014-05-30 18:12:29 52d242a73be2d7d6 3 BAD 2014-05-24 06:27:01 a74d100a121219b8 4 BAD 2014-05-22 04:39:11 941ead2f9ad6f9ca 5 BAD 2014-05-19 09:56:31 c543079b87ce4b6c 6 BAD 2014-05-19 09:16:20 c060947196baef2d 7 BAD 2014-05-19 07:38:04 cac91b6cd17ab746 8 CURRENT 2014-05-19 07:38:04 cac91b6cd17ab746 1 GOOD2014-05-14 16:05:34 ec44f61a831e4225 It's easy enough to reproduce. Create a new empty repository. Add 2 files but only try to checkin 1 of them. Andy -- TAI64 timestamp: 400053891f13 ___ 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] working checkout does not match what would have ended up in the repository
Thus said Stephan Beal on Fri, 30 May 2014 22:25:30 +0200: H. It seems fossil no longer has an option to create the initial checkin. It does using the --date-override option: fossil new --date-override '2014-05-30 00:00:00' test.fossil Will create a new fossil with an initial empty checkin on that date. This does look like one of those corner cases that got missed. Andy -- TAI64 timestamp: 400053892045 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] working with open source code
Hi, Let's say I want to do this setup: Clone sqlite repo on a local server Then clone the server into several machines, with the users pushing changes Then, someday, I will want to update my sqlite base code. In git, one would first fork the code from another repo, add a second remote: git remote add upstream then proceed to work as usual. Then do a: git fetch upstream and even a merge: git merge upstream/master Any recomendation on how to perform something like this, for example, with the sqlite code? Thanks, PS: just in case https://help.github.com/articles/fork-a-repo https://help.github.com/articles/fork-a-repo ___ 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] working with open source code
IIUC: you: fossil clone http://sqlite.org:8080 fossils/sqlite.fsl; cd project_dir; fossil open ~/project_dir/sqlite.fsl; fossil server Each of your our co-conspirators: fossil clone http://your.machine.address:8080 fossils/sqlite.fsl; cd project_dir; fossil open ~/fossils/sqlite.fsl You will: fossil set autosync 0 (because unlikely drh is going to let you push your changes to canonical repo) Your co-conspirators will set autosync to 1 (to sync with your repo auto-magically). You will use the UI to give (eg) developer privileges to the folks that cloned from you, so they can re-push their work to your copy of the repo. Hack, hack. fossil sync, fossil pull, fossil push where necessary. Maybe two peers will sync explicitly between themselves if they're working on something that requires it... What am I missing? On May 30, 2014 9:42 PM, Abilio Marques amarq...@smartappsla.com wrote: Hi, Let's say I want to do this setup: Clone sqlite repo on a local server Then clone the server into several machines, with the users pushing changes Then, someday, I will want to update my sqlite base code. In git, one would first fork the code from another repo, add a second remote: git remote add upstream then proceed to work as usual. Then do a: git fetch upstream and even a merge: git merge upstream/master Any recomendation on how to perform something like this, for example, with the sqlite code? Thanks, PS: just in case https://help.github.com/articles/fork-a-repo https://help.github.com/articles/fork-a-repo ___ 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
