Am 11.01.2011 18:45, schrieb Stephan Beal: > On Tue, Jan 11, 2011 at 1:44 PM, David Bovill <[email protected]> wrote: > >> In my case I'd like to be able to keep track of script elements, handlers, >> functions, methods, classes etc and not the files they happen to be in....in >> a db is much the same, but I am wandering how I can use the db to store >> metadata such as the files the function is found in, so that I can link the >> script elements to these files. >> > IIRC, one user recently posted that he [ab]used the wiki in that manner. He > stored some metadata in wiki pages and fished it out from there. > > If your IDE interface to DVCSs is shell/command based, fossil shouldn't pose > any particular problems for you. That's not the full truth. I'm working on a C# wrapper library around fossil and I encountered some commands which require user input. My problem is that on Windows I can't read the line containing fossils prompt because it isn't terminated by a newline. The Process class I'm using to run fossil only provides an event which is fired after a newline is read from stdout or stderr. I've compiled my own version of fossil where a newline is added to the prompt, so that I can implement the wrapper without waiting for my feature request to be implemented ;) An other pitfall may be the many different answers fossil generates as a response to the different commands. They are readable for human beings, but a wrapper has to parse them, it has to be prepared for different kinds of output layout even for one command when used with different switches, it has to separate information from eye candy and so on and so on. I thought it would be easier as it is.
> However, fossil is a monolithic > application, as opposed to a library with a CLI front-end, which makes it > essentially impossible to write anything _except_ shell-based add-ons for > it. Two or three years ago (has it been that long already!?!?!?) i looked > very closely at how to refactor fossil as a library+app, but by that point > fossil was already so large that the effort involved would have been > tremendous (and fossil has always evolved quickly, so it would not only be a > big target, but a fast-moving one). Such a refactor/rewrite would, however, > make things like GUIs much easier to write. I second this. A library version of fossil is on top of my wish list. Ingo _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
