3 ms·

To clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependen

by Vinnl 3y ago

To clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependent on lock-in to a single vendor like GitHub. Edit: and yes, of course there are downsides as well. It's up to you to weigh them against each other.

prepend 3y ago
I understand, I don’t care about that.
- otp209 3y ago
  Okay? Some of us might want to. As the git people love parroting of its myriad kitchen sink commands, "if you don't like it you don't have to use it". I'd rather have a single integrated tool than the shopping list of "just use X and Y and Z" people are prescribing in this thread for getting the so-called git ""ecosystem"" ""working"". Not that I'll necessarily use all the added features; but the ones I do want being integrated is absolutely relevant to my interests.
mgaunard 3y ago
Yeah, I really want to solve merge conflicts on tickets.
mbivert 3y ago
Versioning/distributing tickets is indeed useful; but can't this be "implemented" in git already, by defining a file-based format (think, issue/$YYYYMMDDHHMMSS-$title.md, but the variants are endless), and versioning those files? A first drawback I can think of is that this would probably require an additional layer for non-tech people. I haven't had the opportunity to use Fossil, so I am clueless regarding the kind of UI they propose, but I wouldn't be surprised that they actually solve this, considering the extensive list of features.
- hn92726819 3y ago
  Well the article does say: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design
  - mbivert 3y ago
    Ah, I probably wasn't clear enough: my point was that the core of the feature (i.e. omitting non-tech users) can be implemented so cheaply that it seems a bit superfluous to require a built-in implementation. However, Fossil's documentation[0] has some answers: Some other distributed bug-tracking systems store tickets as files within the source tree and thereby leverage the syncing and merging capabilities of the versioning system to sync and merge tickets. This approach is rejected in fossil for three reasons: 1. Check-ins in fossil are immutable. So if tickets were part of the check-in, then there would be no way to add new tickets to a check-in as new bugs are discovered. 2. Any project of reasonable size and complexity will generate thousands and thousands of tickets, and we do not want all those ticket files cluttering the source tree. 3. We want tickets to be managed from the web interface and to have a permission system that is distinct from check-in permissions. In other words, we do not want to restrict the creation and editing of tickets to developers with check-in privileges and an installed copy of the fossil executable. Casual passers-by on the internet should be permitted to create tickets. Point 3. indeed requires additional software; Point 2. could be solved by storing the tickets in a distinct repository. Regarding point 1., as far as I understand, a check-in is an atomic series of modifications to the repository database, so it seems there is a strong correlation between the tickets and the "commits"? If so, why not, but I'm not sure why this is necessary either. [0]: https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki

by Vinnl 3y ago

prepend 3y ago

I understand, I don’t care about that.

otp209 3y ago
Okay? Some of us might want to. As the git people love parroting of its myriad kitchen sink commands, "if you don't like it you don't have to use it". I'd rather have a single integrated tool than the shopping list of "just use X and Y and Z" people are prescribing in this thread for getting the so-called git ""ecosystem"" ""working"". Not that I'll necessarily use all the added features; but the ones I do want being integrated is absolutely relevant to my interests.

mgaunard 3y ago

Yeah, I really want to solve merge conflicts on tickets.

mbivert 3y ago

Versioning/distributing tickets is indeed useful; but can't this be "implemented" in git already, by defining a file-based format (think, issue/$YYYYMMDDHHMMSS-$title.md, but the variants are endless), and versioning those files? A first drawback I can think of is that this would probably require an additional layer for non-tech people. I haven't had the opportunity to use Fossil, so I am clueless regarding the kind of UI they propose, but I wouldn't be surprised that they actually solve this, considering the extensive list of features.

hn92726819 3y ago
Well the article does say: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design
- mbivert 3y ago
  Ah, I probably wasn't clear enough: my point was that the core of the feature (i.e. omitting non-tech users) can be implemented so cheaply that it seems a bit superfluous to require a built-in implementation. However, Fossil's documentation[0] has some answers: Some other distributed bug-tracking systems store tickets as files within the source tree and thereby leverage the syncing and merging capabilities of the versioning system to sync and merge tickets. This approach is rejected in fossil for three reasons: 1. Check-ins in fossil are immutable. So if tickets were part of the check-in, then there would be no way to add new tickets to a check-in as new bugs are discovered. 2. Any project of reasonable size and complexity will generate thousands and thousands of tickets, and we do not want all those ticket files cluttering the source tree. 3. We want tickets to be managed from the web interface and to have a permission system that is distinct from check-in permissions. In other words, we do not want to restrict the creation and editing of tickets to developers with check-in privileges and an installed copy of the fossil executable. Casual passers-by on the internet should be permitted to create tickets. Point 3. indeed requires additional software; Point 2. could be solved by storing the tickets in a distinct repository. Regarding point 1., as far as I understand, a check-in is an atomic series of modifications to the repository database, so it seems there is a strong correlation between the tickets and the "commits"? If so, why not, but I'm not sure why this is necessary either. [0]: https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki