3 ms·

Thanks - great input (and the Gollum suggestion is a good starting point!) On multiple VCS: On the one hand, git is so dominant (for better or worse) that I do

Thanks - great input (and the Gollum suggestion is a good starting point!) On multiple VCS: On the one hand, git is so dominant (for better or worse) that I don't know if the complexity is worth it. On the other, perhaps git is so dominant because github is so dominant. The answer in open source land is probably to set up a reasonable abstraction layer and let interested people provide their own implementations of the VCS-interface.

stephenr 12y ago
I think I should also clarify a little.. My key focus for this would be on a more unix-philosophy approach (separate tools that do one thing well). I like the idea of using a VCS repo (again, ideally any of those supported not just git) to store related information such as issues/tickets, etc however I don't know what the practical constraints of that would be, my first thought is that issues/tickets stored primarily in a (version controlled) filesystem (and then presumably indexed on a server for web views, searching etc) would not be as intuitive as say a wiki like gollum. If the issues/tickets tool used a flexible SQL model (e.g. choice of mysql, postgresql and sqlite for instance) I would be happy with that, as the data is still quite open (to the system, owner, not as much to the individual developers admittedly)