4 ms·

> The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync

> The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online. The bug thing I kinda disagree with... or at least I'm skeptical, shall we say. Bugs are solved when the fix has been deployed and verified fixed in production, not when someone commits/pushes/merges a potential fix to the main branch. Sure you can separate the 'bug-X fixed' change to the bug tracker and the code commits, but then what have you gained over just a 'Fixes: X' annotation in the commit msg? This could be misunderstanding on my part about the intent/process around bug/issue handling in Fossil, so I'd appreciate if you could expand on what you like about and how it works within the larger 'deploy a fix' context. (I tried Fossil for a bit on a very small scale -- it was pleasant enough, but ultimately Git's network effects win out big time... at least for me.)

lrem 6y ago
It isn't putting your issue tracking into an equivalent of a git repository. It just contains a rather standard-looking issue tracker, along a wiki for documentation, in the same sqlite. And they are distributed/synchronized just like the repository.
- Quekid5 6y ago
  So they're independent of what happens to the code and just happen to be bundled/synced when the code is?
  - hexmiles 6y ago
    yes
    - deleted 6y ago
      [deleted]
    - Quekid5 6y ago
      Ok, makes sense, but what is the workflow like, then? Would one close the bug along with the fix to the code, or...?
      - ptrott2017 6y ago
        If you include the ticket ID e.g. [ticket-id] in the commit's description, the commit will automatically be linked to that ticket. You can view the list of all associated commits with a ticket by clicking the 'Check-ins' menu item on the ticket's page. When an item is closed - the link appears struck-thru. I dont automatically close tickets on commits - since our workflow is commits get reviewed before closing an item- but it is straight forward to write a small few line script to do this if thats your workflow.
      - ncmncm 6y ago
        Whatever you like. Workflow is a layer on top.
Midar 6y ago
That is only true for projects where you need to deploy. In that case, yeah, you of course can only close the bug once you fixed production. But for normal software development, you can fix the bug in the software and you can update the bug tracker, and then push everything once you're back online. For example, on a flight, I can look at the bug tracker (since it's part of the clone), pick a bug I want to work on, create a few commits to fix it, then update that bug (set it to closed, reference the commits that fixed it), and then upload it all when the plane landed again.

lrem 6y ago

It isn't putting your issue tracking into an equivalent of a git repository. It just contains a rather standard-looking issue tracker, along a wiki for documentation, in the same sqlite. And they are distributed/synchronized just like the repository.

Quekid5 6y ago
So they're independent of what happens to the code and just happen to be bundled/synced when the code is?
- hexmiles 6y ago
  yes
  - deleted 6y ago
    [deleted]
  - Quekid5 6y ago
    Ok, makes sense, but what is the workflow like, then? Would one close the bug along with the fix to the code, or...?
    - ptrott2017 6y ago
      If you include the ticket ID e.g. [ticket-id] in the commit's description, the commit will automatically be linked to that ticket. You can view the list of all associated commits with a ticket by clicking the 'Check-ins' menu item on the ticket's page. When an item is closed - the link appears struck-thru. I dont automatically close tickets on commits - since our workflow is commits get reviewed before closing an item- but it is straight forward to write a small few line script to do this if thats your workflow.
    - ncmncm 6y ago
      Whatever you like. Workflow is a layer on top.

Midar 6y ago

That is only true for projects where you need to deploy. In that case, yeah, you of course can only close the bug once you fixed production. But for normal software development, you can fix the bug in the software and you can update the bug tracker, and then push everything once you're back online. For example, on a flight, I can look at the bug tracker (since it's part of the clone), pick a bug I want to work on, create a few commits to fix it, then update that bug (set it to closed, reference the commits that fixed it), and then upload it all when the plane landed again.