Feature #9703
Define repositories independently from projects
| Status: | New | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | SCM | |||
| Target version: | - | |||
| Resolution: |
Description
It is common for multiple projects to use the same repository. When a repository is set up in a parent project, references to and from children work, although no “Repository” link appears in the children’s primary links. I don’t know whether this is supposed to work or not, since the feature request #1657 about this is not resolved.
I think that it would be more interesting if repositories were defined independently from projects. A project would then select the repository it uses from the list of defined repositories. This could also allow for multiple repositories per project.
Related issues
History
#1 Updated by Hugues De Keyzer 6 months ago
The subject of this feature request should be “Define repositories independently from projects”.
#2 Updated by Etienne Massip 6 months ago
- Subject changed from Define repositories indepently from projects to Define repositories independently from projects
- Category set to SCM
I think it's a dupe too.
#3 Updated by Hugues De Keyzer 6 months ago
#4 Updated by Mischa The Evil 6 months ago
#5 Updated by Colin Mollenhour 5 months ago
This sounds like the best all-around solution, better than #779. It solves duplicate commit messages and the whole parent-child-sibling issue. For me the biggest issue is I have multiple git repos by creating dummy projects under the parent project, but then if there is some commit that references an issue of a sibling repository the connection is not made. With svn I could work around this because I would organize the repo around my sub-project layout but with git having multiple repositories is the only way to control access to specific submodules.
#6 Updated by Andy Bolstridge 5 months ago
I'm not convinced. While it does sound 'clean' to refer to repositories separately, I think most projects will still use unique repositories themselves. Ie, the code for each project does not reside in the same place, either because they are in distinct repositories, or in distinct sub-sections of a single repo.
As a result, we'd end up defining repository links in one place, only to refer to each in the projects - the same could be achieved by placing the repo links directly in the project.
This does not mean that we could take all the repo links for all projects and have them displayed in a report elsewhere that allows the admin to change them (eg if a repo moves).
#7 Updated by William Baum 5 months ago
I really like this idea, and actually considered writing up something similar myself.
I don't see it as inconsistent with #779. It would be great to have available repositories and associate them with projects as need be.. Multiple repositories per project and multiple projects per repository.
Colin, the cross-project revision references thing is easy.. See #3087
#8 Updated by Pedro Gutierrez 5 months ago
I like the idea very much. It would make our life simpler and more flexible.
Mainly because our problem is not that we need multiple repositories for a project, but the other way around, i.e. we'd need multiple projects per repository.
So I'd prefer this solution to the one proposed in #779 . However,I see a number of open issues:
Issue1: Any suggestion on how to grant access to the repositories?
The easiest way, I'd say, would be that repositories had a list of associated projects.And keep the rest as it is at the moment, i.e. the access to the repository granted at role level.
So if I want to push a change to a repository I'd need:
- to be involved in a project with a role that provides access to the repository
- that the project itself be associated to that repository
Issue2: If I'm involved in two projects (with the appriate role). And both projects are sharing a repository how do I associate each commit with the project?
#9 Updated by Holger Winkelmann 8 days ago
We also suggest to have repos independently of projects and assign them to one or more projects,