This just keeps happening. It's not GitHub's fault that they keep getting DDoSed or have a network outage every now and again. But it's not a problem with no solution.
Github is trying their best as far as I can see, they manage to fix the majority of issues within three hours and even during those three hours its not the end of the world because you can still code.
Issue tracking and wikis are not a version control problem. Sure, their data can be version controlled. And documentation has been version controlled since Sccs, why would it require special care?
It doesn't, really, but it's in the same place as the code and everything else (this is what I meant as being "on the same level"). You don't need to clone the code and then clone the tickets, for instance. When you run "fossil timeline" on your local machine, you'll see entries for tickets being closed and wiki pages being updated interspersed among the actual code commits. This is useful to me as they're as much a part of the project as the code itself. Does this answer your question?
An basic example of an org file for tracking issues:
#+title: Project issue tracker
#+description: descr...
#+todo: OPEN(o!) | CLOSED (c@)
This is the issue tracker for Project. In order to add a
new issue, add it to the top of the entries as a plain org
entry, then hit =C-c C-t o= to mark it as open. In order
to close an issue, on it's headline, hit =C-c C-t C=,
this will prompt for a closing comment, see the buffer that
pops up for instructions.
Common tags: docs, features, bugs, security, ideas
* CLOSED Write README. :docs:bookkeeping:
- State "CLOSED" from "OPEN" [2016-03-22 Tue 02:16] \\
Written.
- State "OPEN" from [2016-03-18 Fri 22:33]
* OPEN Implement new features :features:
- State "OPEN" from [2016-01-27 Çrş 23:35]The differences that remain are purely in the interface. For example, although they're synced the same way, VCSes tend to display issues differently than source; it's easier to filter out issue changes from the timeline, and harder to accidentally delete other people’s comments. It also makes it possible for people who aren't actual members of your project to raise and comment on the issues, which wouldn't usually be possible (unless your VCS can manage permissions for each file).
One particular use case of yours that Fossil does support is the ability to have a "wiki/" subfolder and have the web interface automatically format and display the pages inside, so you can link to them more easily if you're using the HTTP server for hosting. I think I use this feature more than the built-in wiki because it’s possible to version the docs along with the source, ensuring they never go out of sync.
Being fair, fossil performance on giant scale projects might not compare quite as well against git or proprietary solutions like Perforce, but for the large majority of projects I expect it is more than adequate.
You can't do patches. You can't rebase. You can't rename files.
Tell me all about this good software and imagination you speak of?
Patches: You can select any 2 commits and create a patch between them ( http://fossil-scm.org/xfer/vpatch?from=cbda43e71bda52f0&to=e... ). If you want to apply the patch, you can just use patch. Whether patch itself should be integrated directly into fossil is I guess something people can argue over. I don't use patches often, but haven't had issues with them.
Rebase: This is what Hipp has to say - http://permalink.gmane.org/gmane.comp.version-control.fossil...
These things may not be exactly how you prefer them, but you're misinterpreting my point about good software and imagination. Almost no software in existence is perfect for everyone in every scenario, but that doesn't also mean that no software is good.
Please do not devolve the conversation by making outlandish statements that have no bearing on the conversation.
>If you need something that works in exactly the way you're used to and that's how you evaluated fossil
That's the exact opposite point I made though. Fossil constrains me in how I work and how I accomplish certain tasks -- with no benefit. Neither Git or Mercurial do that. What Fossil can do, both Git and Mercurial can do better. So why would I choose Fossil?
If you don't get any benefit out of a tool, then don't use that tool. I get value out of it and am not meaningfully impacted by the issues you have with it in practice.
I'm not a salesman and it's free software, so do what makes sense to you.
As an expert on myself, I must disagree.
>If you don't get any benefit out of a tool, then don't use that tool.
I don't use it. But I think you need to remember what I replied to, as that's an ill-placed sentiment in this thread.
You can create bundles and submit them for approval. Very similar.
> You can't rebase.
You have alternatives. The work philosophy is different, though.
> You can't rename files.
False.
Bundles do not have anywhere near the same flexibility and nuanced capacity that patches do.
>The work philosophy is different, though.
That's an apology if I've ever seen one. Again, not the same.
>False.
Rename a file. Then try to merge. Tell me what happens.
Interesting. That's basically what the people who suggested bundles (a Hg feature) said about patches.
I've used both as appropriate. Handy that Fossil has both.
Off-topic, but I'd reccomend that you install HTTPS Everywhere: https://www.eff.org/https-everywhere - the fact that you are linking the HTTP version means you don't have this very basic extension that really improves your security.
Granted, the documentation needs work. But all issues and docs are exposed as git repos.
Fossil tracks issues (tickets), documentation, and wiki pages at the same level as it tracks code, so when you clone a Fossil repo, everything gets downloaded to your local computer. You can then respond to tickets and perform repo maintenance offline, syncing everything to the server when you're back up.
Edit: A few weeks ago I got a job a one-hour train ride away. I can commit, close tickets, and write docs on my way in, sync everything to the internet when I get to work, then do the same on my way back - even though I don't have a net connection during my commute. It works great. (Ok, not as good as not having to travel at all, but great nonetheless!)