14 ms·

Just because present state is 99.7579% uptime (for the month) doesn't mean it will always be so. You back up your data, why shouldn't you backup your github da

Just because present state is 99.7579% uptime (for the month) doesn't mean it will always be so. You back up your data, why shouldn't you backup your github data?

manigandham 9y ago
Backup is one thing, choosing to run a crappy manual system just in case a vendor goes down is entirely different.
- DaiPlusPlus 9y ago
  It doesn't have to be a "crappy manual system" - I'm simply suggesting that given that git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. A simple offline-mode browser-based editor that lives in a single HTML file within the repo would provide a nice GUI on top. Hmm, I think I might be on to something... anyone want to start a project?
  - jasode 9y ago
    >git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. For what it's worth, it's interesting to see that the Fossil distributed SCM includes an issue tracker but they made a deliberate architecture decision to not propagate the tickets data.[1] They had a chance to make your "distributed-issues-tracking" idea a 1st-class concept in Fossil but decided against it. Also, the issues/tickets is just one example feature. Github will continue to evolve to add more and more sophisticatted SDL/ALM (application lifecycle management) like JIRA and Microsoft Team Foundation Server. Those features are not easy to implement in a peer-2-peer SCM with practical usability. [1] https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki
    - DaiPlusPlus 9y ago
      Thank you for the link. I read through their justifications and I think using a git-submodule solves their problems of polluting the main project history and permissions issue. Using directories for mutually-exclusive state grouping (e.g. "closed"/"open"/"new") solves the directory problem.

Just because present state is 99.7579% uptime (for the month) doesn't mean it will always be so. You back up your data, why shouldn't you backup your github data?

manigandham 9y ago

Backup is one thing, choosing to run a crappy manual system just in case a vendor goes down is entirely different.

DaiPlusPlus 9y ago
It doesn't have to be a "crappy manual system" - I'm simply suggesting that given that git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. A simple offline-mode browser-based editor that lives in a single HTML file within the repo would provide a nice GUI on top. Hmm, I think I might be on to something... anyone want to start a project?
- jasode 9y ago
  >git itself is a damned good distributed versioning database for arbitrary content, then we might as well also use it for distributed issue-tracking. For what it's worth, it's interesting to see that the Fossil distributed SCM includes an issue tracker but they made a deliberate architecture decision to not propagate the tickets data.[1] They had a chance to make your "distributed-issues-tracking" idea a 1st-class concept in Fossil but decided against it. Also, the issues/tickets is just one example feature. Github will continue to evolve to add more and more sophisticatted SDL/ALM (application lifecycle management) like JIRA and Microsoft Team Foundation Server. Those features are not easy to implement in a peer-2-peer SCM with practical usability. [1] https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki https://fossil-scm.org/xfer/doc/trunk/www/qandc.wiki
  - DaiPlusPlus 9y ago
    Thank you for the link. I read through their justifications and I think using a git-submodule solves their problems of polluting the main project history and permissions issue. Using directories for mutually-exclusive state grouping (e.g. "closed"/"open"/"new") solves the directory problem.