Re: [fossil-users] How to use triggers

Amazing! Speaking of Jenkins: someone just recently mentioned an existing (dusted though) Fossil plugin for Jenkins. May just be worth a try for your case. Jenkins would automate interactions with Fossil repo, with all benefits of a CI/build server.

Re: [fossil-users] fast-import crash (mark not declared)

To summarize the findings: - Sqlite Fossil repo has a number of special cases that do not export directly, resulting in "git fast-import" crash. - To accomplish the export, one needs to apply the following fixes to the __local__ clone of the Sqlite Fossil repo: fossil set autosync off fossil

Re: [fossil-users] fast-import crash (mark not declared)

Richard, Thank you for the details. I just realized that the check-in date may be altered via "fossil amend --date" or from UI via check-in's edit submenu. This will add the tag "date=" and update the check-ins MTIME. Looks like both timeline and export indeed pick up the updated MTIME. I

Re: [fossil-users] How to use triggers

Script On Feb 16, 2017 11:14 PM, "Warren Young" wrote: > On Feb 16, 2017, at 6:39 PM, Zoltán Kócsi wrote: > > > > The itch I want to scratch is what I described: automated generation of > > binaries and documentation on the server at certain points in

Re: [fossil-users] How to use triggers

On Feb 16, 2017, at 6:39 PM, Zoltán Kócsi wrote: > > The itch I want to scratch is what I described: automated generation of > binaries and documentation on the server at certain points in time. See attached existence proof. :) It’s not exactly Jenkins, but whadda ya

Re: [fossil-users] How to use triggers

> There is not. The difficulty is in the definition of "happens". > > [...] Yes, I get the point and I also have to admit that it was a fairly stupid question. And yes, one should want to run the script only on the server(s) and not on the clients. So, I re-phrase the question: is it

Re: [fossil-users] How to use triggers

On Feb 16, 2017, at 5:51 PM, Zoltán Kócsi wrote: > > Is it possible to (probably yes, but how?) to trigger some external > action when a check-in happens with a particular tag? Sometimes drh is wrong. This is one of those rare times. :)

Re: [fossil-users] How to use triggers

On 2/16/17, Zoltán Kócsi wrote: > Is it possible to (probably yes, but how?) to trigger some external > action when a check-in happens with a particular tag? There is not. The difficulty is in the definition of "happens". We could arrange to run a trigger on the client

[fossil-users] How to use triggers

Is it possible to (probably yes, but how?) to trigger some external action when a check-in happens with a particular tag? For example, if we have a project of which the docs are generated using Doxygen and we want to keep the docs of the latest release on the server as a publicly available HTML

Re: [fossil-users] fast-import crash (mark not declared)

On 2/16/17, Artur Shepilko wrote: > Is this some undocumented Fossil feature which is supposed to allow > overriding of the commit timestamp? Yes. You can change the displayed date of any check-in using a date tag. This feature is designed to fix check-ins that were made

Re: [fossil-users] fast-import crash (mark not declared)

Hmm, another look reveals some surprises: The "future" parent commit (https://www.sqlite.org/src/info/655991ec8a781d67) also has a "date" tag added, apparently in attempt to rectify the timeline: date=2010-09-28 19:16:47 added by [5fd7e19e] on 2010-09-28 19:19:21 Similar situation is with the

Re: [fossil-users] fast-import crash (mark not declared)

Indeed, in export.c the commits are lined up chronologically. There's a way to try to catch such inconsistencies by tracking when the "from :mark" gets freshly incremented (that is the parent has not been exported yet): src/export.c::~581 int next_mark = unused_mark; zMark =

Re: [fossil-users] fast-import crash (mark not declared)

On Thu, Feb 16, 2017 at 02:15:25PM -0800, Ross Berteig wrote: > I'd argue the problem here is with Git. Actually, git is not at fault here. We do the export chronologically as it is much easier to do than computing a topologically sorted output. Joerg

Re: [fossil-users] fast-import crash (mark not declared)

On 2/16/2017 1:11 PM, Artur Shepilko wrote: This fix seems to allow the git fast-import to proceed past this ... until it finds another inconsistency, unrelated to the one above. This time it's with commit: https://www.sqlite.org/src/info/3f30f00a384d2358 Again, looking at the timeline

Re: [fossil-users] fast-import crash (mark not declared)

Looking closer at the timeline and manifests shows that the inconsistency is with https://www.sqlite.org/src/info/590d4ac1ee0db824 which lists as its parent a tag's manifest (https://www.sqlite.org/src/info/f228c7ca0682c370). Normally the link should be to tag's target object, which in this case