Re: [fossil-users] Old problem not entirely gone?
On Tue, Feb 03, 2015 at 01:48:52PM +0100, Jan Danielsson wrote: In terms of the type of data, our data and fossil's data is very different, but in terms of the time it takes to synchronize large data stores/repositories, we're in the exact same situation. We don't expect synchronizations to fail; they rarely will, but it will happen sooner or later, so we were forced to find a way to skip work that has already been done. Correct. One possible approach is to mark new artefacts in a separate to parse table, add them to that list after every round trip and maybe even do a commit in case of power down. Afterwards, process that table. It doesn't even require many changes to the code as the approach taken is essentially the same, just using in-memory storage. 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] New search features
Does anyone have a Windows binary of the latest fossil with search? I don't have the ability to compile it from where I am at the moment. Thanks. Richard On Tue, Feb 3, 2015 at 1:41 AM, jungle Boogie jungleboog...@gmail.com wrote: Dr. Hipp, On 2 February 2015 at 22:11, Richard Hipp d...@sqlite.org wrote: On 2/3/15, jungle Boogie jungleboog...@gmail.com wrote: Something recently has changed that doesn't allow the clicked result to be viewed. http://fossil-scm.org/index.html/tktsrch?s=windows The main Fossil repo (and the main SQLite repo) are now running on a full-text index, rather than do a full scan of all documents for each search. This is faster, but considerably trickier to implement. I expect it to be a bountiful source of errors over the next few days. Not a problem with me, I'll report them as I encounter them! The problem with hyperlinks is now fixed, I think. Please try again. Yes, that corrected it and results are now clickable. -- D. Richard Hipp d...@sqlite.org Thanks! -- --- 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 -- Thank you. Richard Boehme Email: rboe...@gmail.com Phone: 443-739-8502 Work Phone: 410-966-6606 (Mon - Thu 6 AM - 4:30 PM) ___ 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] Old problem not entirely gone?
On 02/02/15 23:23, Warren Young wrote: The annoying thing is that when it fails, it wipes away whatever progress it has made. Yes, well, that’s the nature of transactional DB updates: all or nothing. Implied: There's only one way to use transactions when performing initial synchronizations. How difficult would it be to allow fossil to pick up where it left off in such a case? Are you seriously asking for Fossil to allow a local clone to be in an inconsistent state after an error? I'm working on a distributed storage system which borrows a few of the basic ideas from fossil (immutable artifacts, etc). We perform a DB commit after an entire *application layer* transactional unit has been transferred. When an initial synchronization breaks in our system, we use a simple method to skip artifacts when it resumes; we divide the timeline into week-long chunks, and hash all the artifact hashes in order of time in each chunk; once a week is encountered where the hashes don't match, we perform a fine-grained sync of the artifacts for that week. We deal with up to GB-size artifacts (indexed in DB, but not stored there), and the entire data storage can be in the region of terabytes. The system runs over the regular Internet. It must be tolerant to faults like pull network cable, or ISP hiccups, because restarting from scratch after 90% has been synchronized simply isn't an option. In terms of the type of data, our data and fossil's data is very different, but in terms of the time it takes to synchronize large data stores/repositories, we're in the exact same situation. We don't expect synchronizations to fail; they rarely will, but it will happen sooner or later, so we were forced to find a way to skip work that has already been done. We don't remove all the work which has been done after a failed initial synchronization. Nor do we leave it in an inconsistent state -- we leave it in an incomplete/resumable state, and it's clearly tagged as such. I'm not even asking if fossil could be made fully resumable after an exit either, a An error was detected; retry [y/n]? would be another option. If it's impossible for fossil to do anything like that without major rewiring of the internals, then *that* would be relevant to my question. So to answer your question: No. Not that I ever implied anything of the sort. -- Kind Regards, Jan ___ 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] New search features
https://www.dropbox.com/s/vujnqzgx3iaiu64/fossil.exe?dl=0 From: Richard Boehme Sent: Tuesday, February 03, 2015 1:58 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] New search features Does anyone have a Windows binary of the latest fossil with search? I don't have the ability to compile it from where I am at the moment. Thanks. Richard On Tue, Feb 3, 2015 at 1:41 AM, jungle Boogie jungleboog...@gmail.com wrote: Dr. Hipp, On 2 February 2015 at 22:11, Richard Hipp d...@sqlite.org wrote: On 2/3/15, jungle Boogie jungleboog...@gmail.com wrote: Something recently has changed that doesn't allow the clicked result to be viewed. http://fossil-scm.org/index.html/tktsrch?s=windows The main Fossil repo (and the main SQLite repo) are now running on a full-text index, rather than do a full scan of all documents for each search. This is faster, but considerably trickier to implement. I expect it to be a bountiful source of errors over the next few days. Not a problem with me, I'll report them as I encounter them! The problem with hyperlinks is now fixed, I think. Please try again. Yes, that corrected it and results are now clickable. -- D. Richard Hipp d...@sqlite.org Thanks! -- --- 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 -- Thank you. Richard Boehme Email: rboe...@gmail.com Phone: 443-739-8502 Work Phone: 410-966-6606 (Mon - Thu 6 AM - 4:30 PM) ___ 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] DB error updating ticket
Please try again and let me know if the fix I checked in has cleared
the problem. Tnx.
On 2/3/15, bch brad.har...@gmail.com wrote:
On the fossil site:
SQLITE_ERROR: no such function: stext
SQLITE_ERROR: statement aborts at 26: [DELETE FROM ftsidx WHERE docid
IN (SELECT rowid FROM ftsdocs WHERE type='t' AND rid=1088 AND idxed)]
Database Error
SQL logic error or missing database: {DELETE FROM ftsidx WHERE docid
IN(SELECT rowid FROM ftsdocs WHERE type='t' AND rid=1088 AND
idxed)}
___
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] Old problem not entirely gone?
On Mon, Feb 2, 2015 at 5:35 PM, Warren Young w...@etr-usa.com wrote: After sending that prior message, I did think of a way to allow retries without inconsistency, but it would surely slow Fossil down: there could be a mode that turns cloning into a replay of the master repo’s timeline. That is, every change made to the master gets applied to the slave, in the order it was made. This means local files get updated multiple times, even if later changes wipe out prior ones. The advantage is that after each changeset is applied, the tree is again in a consistent state. I don't think it would be much of a slow down. All the artifacts will get sent, just the ordering will be more controlled. At the start of the first attempt to clone, send the oldest manifest and a cluster listing the remaining manifests in chronological order, plus as many of the files listed in the first manifest as will fit in the initial transfer. Then the client will process the manifests in the order they appear in in the manifest clusters. (If there are too many manifests to list in a single cluster, the final entry in the cluster would be the ID of the next manifest cluster.) When attempting to resume, the client would include the pending gimme cards, also in the order the IDs appeared in the manifest clusters Other than insuring the client receives the manifests in chronological order, the clone protocol would operate as it currently does and would be compatible with clients that don't support resuming. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] DB error updating ticket
On the fossil site:
SQLITE_ERROR: no such function: stext
SQLITE_ERROR: statement aborts at 26: [DELETE FROM ftsidx WHERE docid
IN (SELECT rowid FROM ftsdocs WHERE type='t' AND rid=1088 AND idxed)]
Database Error
SQL logic error or missing database: {DELETE FROM ftsidx WHERE docid
IN(SELECT rowid FROM ftsdocs WHERE type='t' AND rid=1088 AND
idxed)}
___
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] DB error updating ticket
Better.
-bch
On 2/3/15, Richard Hipp d...@sqlite.org wrote:
Please try again and let me know if the fix I checked in has cleared
the problem. Tnx.
On 2/3/15, bch brad.har...@gmail.com wrote:
On the fossil site:
SQLITE_ERROR: no such function: stext
SQLITE_ERROR: statement aborts at 26: [DELETE FROM ftsidx WHERE docid
IN (SELECT rowid FROM ftsdocs WHERE type='t' AND rid=1088 AND idxed)]
Database Error
SQL logic error or missing database: {DELETE FROM ftsidx WHERE docid
IN(SELECT rowid FROM ftsdocs WHERE type='t' AND rid=1088 AND
idxed)}
___
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] configure reset skin resets too much
On 03/02/15 05:50, Joe Mistachkin wrote: [...] Agreed. I'm also of the opinion that this is a good change and I have no objections to it. Awesome. I merged it as [6fedb84abb] and closed the branch. Let me know if there are any problems. ...BTW, while testing I noticed the new file viewer with the tree layout. Very nice! Can't wait for it to hit Debian... -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs. --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
