It's remarkably slow at work so far today, so here's the answer i promised for tonight...
On Mon, Jul 22, 2013 at 2:01 AM, Clark Christensen <cdcmi...@yahoo.com>wrote: > Hi Stephan, > > What you propose sounds like the SQLite model where the core is a lib, and > the part we SCM users interact with is the CLI (or HTTP). From a user's > standpoint, I'd like to assume the project would provide the "default" > executable, equivalent to today's fossil executable. > Yes, of course - a "default binary" would be an absolute must (even if only for testing purposes!). i envision the v2 binary being more or less on parity with v1 in terms of features (eventually). Overall, I have fear that doing it as a lib would take away the > "fossilness" of what I'm used to. Maybe that's to say I have some fear of > change. > But I like Fossil's small size and smallish community. Our community > remains receptive and polite. > i suspect that the "fossilness" of it is what endears many of us to it, and the intention is certainly not to take that away. This is not about replacing fossil, per se, but about changing its basis so that other things can be more easily built around it. e.g. integration of IDE support is a huge PITA right now because there is no clean basis off of which that support can be added. It seems to me that when you publish/maintain an open-source lib, the > entire dynamic of your user base changes from people interested in using > your app, and how to make best use of it, to hard-core developers > trying to build their own product around your lib. Over the past few > years, I've noticed the SQLite users mailing list contains a LOT of > threads about implementing the lib in bigger projects by people who > don't acknowledge there's any documentation. Not only that, but they start their posts with, "we've integrated sqlite into a 120-node cluster, with each one housing 25 GB shards of data in sqlite3, and we've hit what appears to be a limitation..." i have no sympathy for them ;) > Or the conversations dig > deep into C topics like pointers, memory management, and the like. > Anyway, I guess my point is, there's a lot less interesting for me there > than there once was. And I'd hate for Fossil to go that way. Probably > selfish of me. > Ideally we can keep the pointer discussions to the fossil-dev list ;) > OTOH, from a technical standpoint, it does seem like the right approach. > Agreed. > * ticket event notifications, or a table where they're queued for some > other process to retrieve/send them. > Maybe this is a special case of moderation (or maybe moderation is a special case of this)? > * built-in full text search for tickets. > Searching has been one of the most-requested features for fossil lately. The main difficulty is that it's not as simple as "select * from xyz where field like ..." because artifacts are stored as deltas (which are useless for searching purposes). So to search an artifact its body has to be recreated from its baseline and deltas. To find out what version of a file a given search term was in we have to rebuild _every_ version of that file and then remember them long enough to be able to report the search results to the user. Take a large file, llke sqlite3.c, try to search through its whole history for the word "sqlite" and you'll probably spend the rest of the day waiting on fossil to calculate the results. It "might"(???) make more sense to provide searching as an extra tool which effectively builds a cache of a "deconstructed" repo, containing "expanded" copies of all artifacts, and performs searches against them. -- ----- 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
