4 ms·
That's an interesting point in light of Rails' recent movement towards more modularity. It suggests that there may be room for a Fossil-like abstraction over Gi
by nex3 16y ago
That's an interesting point in light of Rails' recent movement towards more modularity. It suggests that there may be room for a Fossil-like abstraction over Git that has (pluggable?) built-in cloned-by-default issues, wiki, etc.
- sophacles 16y agoHonestly 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.