4 ms·
Honestly I've always wondered why redmine, trac, et al don't already build their wiki on top of the vcs anyway, instead of using a separate database with tracki
by sophacles 16y ago
Honestly I've always wondered why redmine, trac, et al don't already build their wiki on top of the vcs anyway, instead of using a separate database with tracking. Such a step seems counter-productive.
- nex3 16y agoI can see arguments both ways. Having the wiki separate means that the repo doesn't get polluted with unrelated commits (especially important for SVN which doesn't have branches), and it makes setup at least somewhat easier, since an extra push-capable user doesn't need to be added.
- bruceboughton 16y ago>> (especially important for SVN which doesn't have branches) explain.
- nex3 16y agoSubversion doesn't have a built-in notion of branches in the same way that distributed systems do. Instead of being names for nodes in the DAG of commits, branches in Subversion are usually handled by manually maintaining separate versions of the same code in a branches/ subdirectory. In a distributed system, you could keep a wiki or bug database on its own branch, and commits to that branch wouldn't be visible if you only cared about the main branch. In Subversion, those commits would be visible, because it's all part of the same tree. One caveat: Subversion's branch management may have changed since I last looked (version 1.5 or so). However, systems like Trac and RedMine were designed when branches worked as I described above, so it still serves to explain their rejection of SCM-backed storage.