Re: [fossil-users] libfossil minor milestone: tag app
On Wed, 14 Aug 2013 18:40:55 +0200, Stephan Beal sgb...@googlemail.com wrote: libfossil is the tentative name for (as you correctly guessed) an experimental library API for fossil. It's still a long way from being fully functional but some features already work: http://fossil.wanderinghorse.net/repos/f2/ PS: the name libfossil (or libfossil-scm) is still the working title - if you have suggestions for better name then feel free to suggest it. Sounds perfect. I also agree Fossil should be available as a DLL so that it can easily be packaged with a non-web GUI front-end. ___ 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: tag app
On Sun, 11 Aug 2013 23:44:10 +0200, Stephan Beal sgb...@googlemail.com wrote: Another status update for what is still tentatively known as libfossil... What is libfossil? Fossil.exe turned into a library so it can be used from another application like SQLite? ___ 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: tag app
On Wed, Aug 14, 2013 at 1:27 PM, Gilles gilles.gana...@free.fr wrote: On Sun, 11 Aug 2013 23:44:10 +0200, Stephan Beal sgb...@googlemail.com wrote: Another status update for what is still tentatively known as libfossil... What is libfossil? Fossil.exe turned into a library so it can be used from another application like SQLite? Hi, Gilles! libfossil is the tentative name for (as you correctly guessed) an experimental library API for fossil. It's still a long way from being fully functional but some features already work: http://fossil.wanderinghorse.net/repos/f2/ PS: the name libfossil (or libfossil-scm) is still the working title - if you have suggestions for better name then feel free to suggest it. -- - 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] libfossil minor milestone: tag app
On Mon, Aug 12, 2013 at 12:44 AM, Stephan Beal sgb...@googlemail.comwrote: Hi, all, Another status update for what is still tentatively known as libfossil... I have a small question about libfossil - is the http server considered part of the lib, or part of the app? If the app, are wiki pages an integral part of Fossil, or are they just another type of artifact that the app can choose to display in a special format? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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: tag app
On Mon, Aug 12, 2013 at 12:03 PM, Baruch Burstein bmburst...@gmail.comwrote: On Mon, Aug 12, 2013 at 12:44 AM, Stephan Beal sgb...@googlemail.comwrote: Hi, all, Another status update for what is still tentatively known as libfossil... I have a small question about libfossil - is the http server considered part of the lib, or part of the app? Good morning! It's neither - it's at least 4-6 months from being that far along :/. When it is, i would like for the networking bits to live in a layer between the core lib and the application (if that's possible/feasible - i'm not yet certain that it is). But that's still far enough away that i have no concrete plans regarding it (but it is of course on the radar). Ideally the library itself will have zero dependencies on any sort of transport layer (HTTP/SSH) and can instead work over an abstract i/o interface (which is already in place but may not be sufficient - time will tell). If you have concrete ideas regarding such details, please feel free to make suggestions. If the app, are wiki pages an integral part of Fossil, or are they just another type of artifact that the app can choose to display in a special format? Yes. Both, actually - they are just plain old artifacts and how they are rendered is then determined by their type. Where exactly the line is between app-level and lib-level responsibilities is not yet clear. Last night i ported in the bits which generate the timeline entries when a tag is created, and found that it contains a huge amount of presentation code which is only relevant for fossil(1), e.g. how it generates links. i am not yet certain how i will be able to provide hooks so that people can, for example, write their own native-language timelines. http://fossil.wanderinghorse.net/repos/f2/index.cgi/artifact/f90fd404ae13676511aaa5b236d820026166ed22?ln=1269-1333 ideas are welcomed :). -- - 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] libfossil minor milestone: tag app
On Sun, Aug 11, 2013 at 11:44 PM, Stephan Beal sgb...@googlemail.comwrote: [stephan@host:~/cvs/fossil/f2]$ f time -t g -n 2 === 2013-08-11 === 21:31:39 [64df2f9505] Edit [2caba4c8]: Add -tag-test-3 with value again!. Or... [stephan@host:~/cvs/fossil/f2]$ ./f-timeline -n=3 ci [7ee249619506] @ 2013-08-12 07:25:07 by [stephan] in branch [trunk] Started down the load road to manifest parting, but it's time for sleep. ci [06fe4570c872] @ 2013-08-12 07:24:42 by [stephan] in branch [trunk] Corrected integer type passed to fsl_md5sum_cstr(). ci [503857bab7d1] @ 2013-08-12 06:30:44 by [stephan] in branch [trunk] Changed how config header is generated to give me more control over the content. http://fossil.wanderinghorse.net/repos/f2/index.cgi/wiki?name=f-tools -- - 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] libfossil minor milestone: tag app
On Mon, Aug 12, 2013 at 1:03 PM, Stephan Beal sgb...@googlemail.com wrote: the radar). Ideally the library itself will have zero dependencies on any sort of transport layer (HTTP/SSH) and can instead work over an abstract i/o interface (which is already in place but may not be sufficient - time will tell). If you have concrete ideas regarding such details, please feel free to make suggestions. Back to that for a moment... i'm trying to keep the library as ignorant as possible of i/o. All operations on the db happen in terms of content in memory, not files (at least not at this point). Even though your repo db might name a certain blob my-file.txt, it doesn't ever have to exist in the filesystem as a file as far as the library is concerned. My goal is to have the core library not deal with any i/o outside of (A) the db files and (B) generic i/o interfaces which take data from or feed data to the user (but the user provides the i/o routines, so the library can use arbitrary i/o channels). For the sake of usability and memory-use, there will need to be at least some core support for working with files (e.g. checking in/out from/to disk instead of memory), but i'm still a good ways away from knowing what that API might eventually look like. Suggestions and bikeshedding are welcomed. -- - 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
