[fossil-users] massive shunning
Hello, recently I switched from Gnucash to Ledger to keep record of my our finances and everything is under Fossil. The dbstat of the repo looks as follows: repository-size: 428815360 bytes (428.8MB) artifact-count:7731 (stored as 5556 full text and 2175 delta blobs) artifact-sizes:988004 average, 7115776 max, 7637276295 bytes (7.6GB) total compression-ratio: 17:1 check-ins: 1238 files: 5996 across all branches wiki-pages:0 (0 changes) tickets: 0 (0 changes) events:0 tag-changes: 23 latest-change: 2015-04-13 11:28:04 - about 0 days ago project-age: 1155 days or approximately 3.16 years. project-id:de5578af6cd61b7f042995c2d074bc2667eb2500 schema-version:2015-01-24 fossil-version:2015-03-14 15:21:53 [39f084cf2c] [1.32] (gcc-4.8.3 20141208 [gcc-4_8-branch revision 218481]) sqlite-version:2015-02-25 14:25:31 [6d132e7a22] (3.8.8) database-stats:418765 pages, 1024 bytes/pg, 2748 free pages, UTF-8, delete mode Due to enormous amount of files in the repo (Gnucash is creating lot of temporary/log files in order to be able to recover) I had to even disable repo-checksum to improve performance. The last version of my *.gnucash file is 6.8M, while the ledger file is ~700K and I actually need only to keep that single file under Fossil, so I wonder if there is some way to do 'massive shunning' of all those old gncuash's tmp/log files in order to trim number of files in repo to only two: file.gnucash and file.ledger? (I'd like to keep the *.gnucash's file as history record as well as for checking point while fully migrating to Ledger). Fossil's admin provides UI for shunning, but I'm looking for some shortcut to quickly shun most of those 6K files? Sincerely, Gour -- In this endeavor there is no loss or diminution, and a little advancement on this path can protect one from the most dangerous type of fear. ___ 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] Two trunks?
Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200: > I'll do more testing on the "sync-forkwarn". Thanks. One thing to note is that I extended the function fossil_find_nearest_fork to be able to work without checking the vmerge table which is only available for a repository that is open, however, fossil sync may actually be run with -R and there may or may not be a vmerge table for that. Perhaps a better option would be to check for the vmerge table if it exists and use it, otherwise don't? Thanks, Andy -- TAI64 timestamp: 4000552c8dca ___ 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] Two trunks?
Thus said Matt Welland on Mon, 13 Apr 2015 15:57:53 -0700: > Does fork notification really warrant another setting? Generally, I would prefer to avoid another setting, but wanted to make sure. > Forks are rare in most repos (the intensely busy repos I deal with > seem to be the exception). Given these points surely a fork warning is > a harmless or at worst mildly annoying rare occurrence so please make > it the default behavior or make it non-configurable. I agree that for repositories where forks are rare, it is a minor nuisance at worst. It may be helpful in most cases if the fork didn't get noticed for a while, but it may also alert people who are disinterested (e.g. working on a branch in which there are no forks) if the fork isn't merged before they pull it in. I suppose notifying the committer that a fork has occurred during their sync operation may cause the fork to be merged more quickly thus minimizing the number of folks who will actually see a warning. If my SQL is correct, there have been 74 forks in Fossil since 2007. It would seem that many of the early forks were due to either not having branching, or using the fork as the branch. Later commits to Fossil seem to involve fewer forks and more branches. This year so far has only seen 1 unintentional fork: http://www.fossil-scm.org/index.html/timeline?n=25&y=all&v=0&c=2015-03-30+20%3A34%3A39 It would seem that the frequency of forks is low for Fossil. I suppose worst case, we merge sync-forkwarn to trunk and see how it fares prior to the next release. Andy -- TAI64 timestamp: 4000552c8ccd ___ 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] Two trunks?
On Mon, Apr 13, 2015 at 1:59 AM, Jan Nijtmans wrote: > 2015-04-13 6:31 GMT+02:00 Andy Bradford : > >> It's not yet merged to trunk, but I have borrowed from Jan's work and >> merged into the sync-forkwarn branch for what I think will provide a >> better experience (e.g. almost no false positives). >> >> I say almost none, because it's possible that if your sync is cut-off, >> you may end up with a node that has a fork which has already been >> merged, but for which you didn't receive the correction (what are the >> odds?). >> >> But on the whole, I think this is much more reliable: >> >> https://www.fossil-scm.org/index.html/info/d0e2f1bd3e71ebf6 >> > On a branch with a fork if I do "fossil up " I do not get a warning about the fork. fossil status => no warning (expected I think from the conversation) fossil up branchname => get warning fossil up => get warning Pretty nice. I'd have liked fossil status to report forks but as is this covers most scenarios. > > Just two remarks: > - I'm not sure if I want to be reminded when someone else causes a > fork on a branch I'm not working on. But if there is such a desire > with other people, I'm not principally against it. > - The function primary_parent_pid_from_rid() is not used anywhere. > > I went ahead, so the fork detection for fossil update/status/info > (I din't hear anyone against that) will receive some more > wide-spread testing. I'll do more testing on the "sync-forkwarn". > > Any more feedback welcome! > > Regards, >Jan Nijtmans > > > ___ > 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] Two trunks?
Does fork notification really warrant another setting? If there is a fork on some other branch either fix by merging it or rename one of the legs. There is no sensible need for a fork to exist in a timeline that I can think of. Forks are rare in most repos (the intensely busy repos I deal with seem to be the exception). Given these points surely a fork warning is a harmless or at worst mildly annoying rare occurrence so please make it the default behavior or make it non-configurable. On Mon, Apr 13, 2015 at 8:25 AM, Andy Bradford wrote: > Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200: > > > - I'm not sure if I want to be reminded when someone else causes a > > fork on a branch I'm not working on. But if there is such a desire > > with other people, I'm not principally against it. > > I asked a question a few days ago about whether this kind of > notification should be opt-in (e.g. a setting that is disabled by > default). I never got feedback on it. > > > - The function primary_parent_pid_from_rid() is not used anywhere. > > Yes, thank you, I forgot to remove it. It became obsolete after using > fossil_find_nearest_fork was written. :-) > > Thanks, > > Andy > -- > TAI64 timestamp: 4000552bdff7 > ___ > 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] Two trunks?
Thus said Jan Nijtmans on Mon, 13 Apr 2015 10:59:38 +0200: > - I'm not sure if I want to be reminded when someone else causes a > fork on a branch I'm not working on. But if there is such a desire > with other people, I'm not principally against it. I asked a question a few days ago about whether this kind of notification should be opt-in (e.g. a setting that is disabled by default). I never got feedback on it. > - The function primary_parent_pid_from_rid() is not used anywhere. Yes, thank you, I forgot to remove it. It became obsolete after using fossil_find_nearest_fork was written. :-) Thanks, Andy -- TAI64 timestamp: 4000552bdff7 ___ 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] Two trunks?
On Fri, Apr 10, 2015 at 2:16 PM, Matt Welland wrote: > I myself prefer not to see additional info like this that can be derived > from querying the db added to the timeline. I'm keen to see the work that > Andy and Jan have done make it into the trunk and will test it ASAP. > There is a difference between "derived from querying the db" and just querying the db. If a FORK tag is auto-added, it can be queried just like any other tag. ___ 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] SSL Cert expired
On 4/13/15, Volker Braun wrote: > Richard Hipp writes: >> Thanks everybody for letting me know that the SSL cert for SQLite and >> Fossil has expired. We are working the problem now. It is OK to stop >> sending me emails about it. > > The SSL cert is updated now, thanks. But you removed the > intermediate certs, so users can't (easily) verify the cert > unless they happen to have them. Apparently Chrome bundles the > intermediate certificates, but they are not required and > e.g. wget now fails. The intermediate certificates were included > previously, with the now-expired sqlite cert. See e.g. > http://stackoverflow.com/questions/25213923/ssl-site-and-browser-warning > Mike reports that the problem should be fixed now. -- 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] Two trunks?
2015-04-13 6:31 GMT+02:00 Andy Bradford : > It's not yet merged to trunk, but I have borrowed from Jan's work and > merged into the sync-forkwarn branch for what I think will provide a > better experience (e.g. almost no false positives). > > I say almost none, because it's possible that if your sync is cut-off, > you may end up with a node that has a fork which has already been > merged, but for which you didn't receive the correction (what are the > odds?). > > But on the whole, I think this is much more reliable: > > https://www.fossil-scm.org/index.html/info/d0e2f1bd3e71ebf6 > Just two remarks: - I'm not sure if I want to be reminded when someone else causes a fork on a branch I'm not working on. But if there is such a desire with other people, I'm not principally against it. - The function primary_parent_pid_from_rid() is not used anywhere. I went ahead, so the fork detection for fossil update/status/info (I din't hear anyone against that) will receive some more wide-spread testing. I'll do more testing on the "sync-forkwarn". Any more feedback welcome! Regards, Jan Nijtmans ___ 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] SSL Cert expired
Richard Hipp writes: > Thanks everybody for letting me know that the SSL cert for SQLite and > Fossil has expired. We are working the problem now. It is OK to stop > sending me emails about it. The SSL cert is updated now, thanks. But you removed the intermediate certs, so users can't (easily) verify the cert unless they happen to have them. Apparently Chrome bundles the intermediate certificates, but they are not required and e.g. wget now fails. The intermediate certificates were included previously, with the now-expired sqlite cert. See e.g. http://stackoverflow.com/questions/25213923/ssl-site-and-browser-warning $ wget https://sqlite.org --2015-04-13 09:49:13-- https://sqlite.org/ Resolving sqlite.org (sqlite.org)... 67.18.92.124, 2600:3c00::f03c:91ff:fe96:b959 Connecting to sqlite.org (sqlite.org)|67.18.92.124|:443... connected. ERROR: cannot verify sqlite.org's certificate, issued by ‘CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB’: Unable to locally verify the issuer's authority. To connect to sqlite.org insecurely, use `--no-check-certificate'. $ echo | openssl s_client -connect sqlite.org:https | head depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = sqlite.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = sqlite.org verify error:num=27:certificate not trusted verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = sqlite.org verify error:num=21:unable to verify the first certificate verify return:1 DONE CONNECTED(0003) --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=sqlite.org i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA --- Server certificate -BEGIN CERTIFICATE- MIIFfDCCBGSgAwIBAgIRAPJaj7w2t7gtSUtULd/3HVcwDQYJKoZIhvcNAQELBQAw gZAxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
