[gaxun]

I'm reading the page on how the distributed bug tracking works. I've heard of Fossil before but never dug too deeply.

> But if a timestamp on a ticket change artifact is off by months or years, it can seriously confuse the replay algorithm for determining the current ticket state.

I understand the simplicity of merging all the ticket comments by timestamp, but couldn't they at least include a reference to one or more recent comments to help establish order when clocks are off? Still wouldn't avoid intentional bad actors, but there are bound to be people with misconfigured clocks.

If I'm working on a Fossil repository and I want to see what bugs everyone else has reported, where do I go to get a list of other copies of the repository so I can query them for new bug reports? Is there some kind of tracker that lists all the people currently publishing the same Fossil repository, so I can connect to each one and ask for updates?

I wrote a post [0] on my site about this concept recently. It's not really polished, I think the thoughts were incomplete. It was written in the context of git due to its ubiquity these days, but the concept should apply the same to other DVCS. I know I'm full of a lot of questions and few answers, but questions help me learn.

[0] https://www.gaxun.net/ideas/git-announce/

[noobermin]

>I've heard of Fossil before but never dug too deeply.

Pun not intended?

[wyoung2]

> there are bound to be people with misconfigured clocks.

Let's step back a bit here, and realize that ticket tracking is typically one of the things you restrict access to in a Fossil repository. You're either running a private instance and have the whole repo locked down, or you're running a public instance and at least require a valid login before users are allowed to post tickets. The SQLite.org repo doesn't even allow normal users to post tickets; that feature is restricted to the core development team, with public-originating items going into the ticket tracker only after being discussed on the mailing list first.

(This policy also eliminates ticket spam.)

Therefore, the number of users that can confuse Fossil this way is small, and the Fossil server admin probably knows how to contact all of them.

Given that, the only way you're likely to confuse Fossil via this weakness is to have two people with clocks maybe a large fraction of an hour off both modifying the same ticket within an hour's span, so that the person with the bad clock appears to be making comments before the comments from other users. (Or vice versa if the clock error is in the future direction.)

So, we have an error case that can only happen among a small number of users, and only when someone isn't using NTP like they ought to, and then only when we have multiple users modifying a particular ticket in a small time window, and when it happens, it only causes a bit of web UI weirdness, not data corruption.

There's your answer, then: why spend much time fixing an extremely rare case with such minor consequences?

If it really bothers you, the Fossil project regularly accepts outside contribution patches.

> where do I go to get a list of other copies of the repository so I can query them for new bug reports?

You don't have to. Fossil syncs all artifacts back to the repo it cloned from, not just code artifacts. This includes not only tickets, but also wiki articles, etc.

The only weakness here is that Fossil's autosync feature doesn't happen on certain types of updates, including ticket changes, so you have two choices: manually say "fossil sync" to push ticket changes to the central repo, or wait until the next code commit, which will gather up the ticket changes and send those along with the code commit.

I don't know why Fossil doesn't autosync local ticket changes, but I'm sure it's purely a matter of development time and will, not a designed-in weakness. If you want remote fossils to autosync their local ticket changes, it should be easy to add the feature.

> Is there some kind of tracker that lists all the people currently publishing the same Fossil repository

In the context of your blog post, Fossil generally isn't run in the git "just fork me" mode of operation. It can run that way, but it's much more commonly used in the central-plus-clones model, where there is a canonical central repository and a working clone on each developer's machine.

This mode is encouraged by the Fossil autosync feature being turned on by default, which means each local checkin also syncs to the central repo.

You can turn autosync off, in which case Fossil works more like git, where a clone is allowed to go off on its own tangent relative to the repo it cloned from. However, that buys you many of the problems of Git relative to Fossil, such as that merging can be a pain. Autosync greatly increases the chance that any given commit will apply cleanly.