On Mon, 13 Mar, Richard Hipp wrote: > I'm a little confused. If you need to continue using Fossil 1.29 for > text output compatibility, then why is it a problem that you cannot > "fossil update" to the latest trunk? After all, you won't be using > the latest trunk, right?
Ha, right, that's a little bit complex, too. ;-) There are two use-cases of fossil for us. 1) We use fossil as a SCM for generated files during software build processes, i.e. source code that is not stored in the primary version control system at customer site in order to retrieve generated files consistent to a certain state of source code. 2) We are using fossil trunk source code itself to run our static code analyses against - kind of regression test. For #1 we still use fossil 1.29 because of the command line compatibility issue. For #2 we used fossil trunk up until now, but this gave us the issue initially brought up with my posting. > Also: What can we do to help you move away from scripts that depend > on the details of command-line output and toward something that is > more likely to survive an update? Indeed something like fossil timeline --json ... fossil status --json ... fossil ls --json ... fossil blame --json ... where we can rely on the output in the future. > What are your scripts doing? We are using the following commands (for various scenarios): timeline, update and pull (in order to sync to a certain repository state), status and ls (in order to find out which file is in which revision in the working tree), cat (to retrieve a file in a specific version), blame (to find out which author changed which line in a file last), clone and remote (in order to initially set up a repository clone automatically), init, settings and open (in order to create a repository and put it in a specific usable state), user, addremove and commit (in order to store the latest batch of generated files in the repository). > Would it be better to run SQL queries directly against the repository > database? I fear that the SQL schema changes more often than the command line. :-/ > Are new fixed-output-format commands needed in Fossil to > extract information that is important to scripts? It indeed would be nice to have a fixed-output-format, defined once and used (in a compatible way) in the future. This could be very well JSON. Greetings, Stefan -- Stefan Bellon _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
