Redmine

I second this.

We have 1 svn repository that houses all our projects under separate paths. At first, I was fine with just making each project point to a specific path within the repository, but now we're having issues linking revisions and using revision comment commands.

The problem comes into play because of our layout, which we're not willing to change as it's tied to how we want to do it. We have some projects that have trunk/tags/qa/etc subfolders, and then within each of those are the subproject folders, rather than each having their own trunk/tags/etc.

This means that any time we commit to a branch or our qa commits, they don't work with redmine, as the repository for the project is configured as superproject/trunk/subproject, so we can only use redmine associations on trunk commits, which doesn't let us track other things that we use redmine issues for.

I'm not exactly sure how you would resolve this and still not screw up other cases where revisions numbers aren't transferable across projects. One way I'd think would be to look at the repository path, and tell that one is a subset of another, but that could be tricky and not guaranteed to always remain the case if someone later changes the repository.

Another might be to define repositories outside of projects, and then let each project choose from a list of repositories, with additional per-project settings, like the path within the repository to use for repository browsing, but still allow revision links that weren't committed to that path. Something like this would also seem to be what the person above is asking for. I also like this because it allows a single authentication mechanism for the repository, which was quite annoying to change when we changed username/passwords and have to go to every single project (there's a lot) and change them all individually.

I like this too.

I have a lot of projects contained within a single repo. I'd love to be able to set the repo centrally, and then have redmine projects associate with paths inside that repo.

Alternatively to the 'single repo' approach is to associate a repo with a project, and allow sub-projects to be path-based on the parent's repository. This would make sub-projects more closely related to a project.

+1!

+1

+1