Create milestone from fossil command line

Hello, I’d like to create an automated build of our software. For this, I must create the vcs_repo.sqlite database from the LUA code.

There are very good explanations about this and , but when I open Iguana with this database, all channels have an error: “No milestone is saved. The channel cannot be run.” I must open all channels in the translator and save a milestone, which is of course not possible in an automated build.

How can I automate this step? What is the command line syntax for fossil to save a milestone on a channel?

You can use the channel API:

http://help.interfaceware.com/kb/897#save_project_milestone

I think the miletones work by concatenating the GUID of the translator instance with the comment and tagging everything. In theory one could do with with the fossil command line. If you felt adventurous you could replace the fossil.exe in Iguana with a batch script which could log the commands Iguana invokes to save a milestone.

I personally don’t love the complexity of what Iguana does here to save a milestone and it’s a system I’d like to overhaul, simplify and make more general.

Incidentally we’re working on a little Iguana web app called Channel Manager which uses the channel RESTful API to export and import entire channels from a running Iguana.

Which company do you work for – curious to know who is automating Iguana builds.

Hi Eliot,

indeed I was feeling adventurous, and it seems that the command line looks more or less like this:


fossil commit -f --user-override admin -m __(channel guid)__(milestone name) --tag __(channel guid)__(milestone name) (channel guid)\main.lua (channel guid)\project.prj shared\(all shared lua files) other\(all other files)


So I just have to figure out which shared and other files have to be added to each milestone.

About your other question, I work at Qiagen… but I’m surprised how unusual this idea of automated builds seems?

If I want to deploy an Iguana solution to a customer, I wouldn’t want to burden him with the whole history of embarrassing bugfixes. So I have to bake him his own SQLite database. And if I want to make a build in one step, this must be completely automated. So I don’t get bored by performing always the same steps, I don’t forget anything, and the build is performed in a controlled environment. I could even write some unit tests with LuaUnit or something like that!

Ah sorry I wasn’t following this thread either. I have to remember to always click on the notify me of follow up replies via email. Sorry for my slow reply.

Yeah to be absolutely honest I’m not that crazy about how the fossil bindings were done in the translator. A big part of the issue was that the developers who built the bindings weren’t really familiar with how distributed source control systems like Mercurial, Fossil and Git are meant to be used.

There are a lot of subtleties in how you are meant to use these systems.

We since shifted our internal source control over to Mercurial – at the time the fossil bindings were done we were stuck on CVS and the fossil bindings were implemented in the manner that someone familiar with CVS would do them – groan 🙁

I think our fossil bindings try to hide what is going under the hood too much.

I guess one consolation is some of our competitors do source control even more badly. I know of one of them which does the old school ‘locks’ on files – only one person is allowed to edit a file at time. That goes back to RCS days…ugh.

With the channel manager and working with GIT it’s a good opportunity to really grok how these source control systems are really meant to work. The Iguana Apps project is as much about the social problem of how do you lead a team of software engineers to really understand the problem of your customers – the traditional model of fronting up a non technical product manager doesn’t really work in my opinion you get very mediocre results from this type of process:

One of problems with unfettered access to a dev team is that you get a whole of features crammed into product which then become hard to maintain. I think we the apps project we can have a quite a lot experimentation, figure out what really works and then fold the best ideas back into the core of Iguana. A key part of making the apps project successful is documenting and making each part transparent and obvious to a broad audience. It takes an effort…

Any chance we can get you to Toronto – just looking over your posts – you are obviously pretty bright – your questions are good. It would be nice to meet you in person.

Incidentally to figure out what files a project has it’s easy enough. It’s in a JSON file with the extension prj that goes into the root directory of each translator instance:

https://github.com/interfaceware/iguana-web-apps/blob/master/Webservice%20-%201.%20Service_http/project.prj

Beware though that we’re very slightly to change the revise this in the future…