4 ms·
This seems like a conflation. Your repo issues could be stored in a SQLite database, or a flat list of JSON files, or a git repo, or a giant text file, any of w
by RyanCavanaugh 8y ago
This seems like a conflation. Your repo issues could be stored in a SQLite database, or a flat list of JSON files, or a git repo, or a giant text file, any of which your host might or might not give you direct access to.
The thing to consider (if portability is your primary concern) isn't the underlying storage format, it's whether or not you have a straightforward way to move it between providers.
- mkirklions 8y agoI didnt understand why this mattered either. One is storage of data that can be downloaded whenever, the other is basically a comment field.
- crossman 8y agoCouldn't agree more. It seems naive to think that source control would be a good system for the kind of operations performed in issue tracking
- icebraining 8y agoIssue tracking is all about managing changes to objects (issues) made over time by multiple people from different machines. Seems like a perfect case for VCS to me.
- yrashk 8y agoI thought so, too and developed SIT (https://sit.fyi https://sit.fyi). An interesting thought that I had initially helped me make it even more future-proof: Git is likely not here forever, it'll probably get replaced with something else in due time. So I designed SIT to be both merge-conflict-free and SCM-independent by relying just on additive sets of files.
- Skunkleton 8y agoA VCS might be a good storage location for these 'objects', but it certainly doesn't provide the structure to manage them.
- bachmeier 8y ago> Your repo issues could be stored in a SQLite database, or a flat list of JSON files, or a git repo, or a giant text file That's exactly what Fossil does, and the creator has urged Git to do the same.