In non-trivial setups, the ability to group and organise Diffusion repositories would be very useful to both organise code into various sections (libraries, tools, etc.) and present access to various projects in a much more constructed manner for anyone wanting to publically browse the source code of unrelated projects.
Revisions and Commits
Summary from discussion in IRC:
- There's an existing "shortcuts" mechanism with no edit UI that's used only by Facebook, which serves similar but slightly different purposes.
- There's been virtually no demand for anything in this vein from other installs.
I expect we'll eventually improve the state of the world here, but would like to see more use cases before we do.
T2298 seems like a more tightly scoped version of this task - basically adding a little select or something that lets you choose the sort order of the repositories by name or most recently committed to.
We're based mostly on github, so we have organizations (basically team) that own repos; this adds up to lots of small repos.
Diffusion view isn't (?) sorted, so looking for a repo there is annoying.
Oh, I forgot this existed -- good find. T3935 overlaps in some ways.
One note is that the original task predates ApplicationSearch -- at the time, it wasn't possible to filter or reorder repositories at all. However, I suspect ApplicationSearch hasn't done much for the high-count installs.
This isn't much of an issue any more. For me, I simply defined a search called "Important Repositories" with the callsigns I'm interested in. It might be nice to allow administrators to make their searches public (so for example I could set "Important Repositories" as the default for anyone opening Diffusion), but it's not critical at all. I'm generally of the opinion that having the dashboard public and showing recent activity will be of much more use than this task.
First of all, a bit on our use case: We have a great number of repositories (central project alone consists of >40 modules (which will increase); add tools and lib-forks to that).
Being able to group repositories into projects already helped a lot. However, after doing so additional functionality was missing to effectively work with it:
- Set up search queries for everyone (like the built-in queries) in order to display projects repositories
- Repository listing in the projects detail page
For reference, I found the built-in queries logic to be in PhabricatorRepositorySearchEngine.php, functions getBuiltinQueryNames and buildSavedQueryFromBuiltin.
In the end, we grouped the repositories into projects, hacked built-in queries for diffusion per project, and extended the project page to list repositories.
We created several Phabricator projects for our one project. One for the main components spanning multiple repositories (for unique component versions), one for secondary components like library forks and project specific tools, one for tools like our Phabricator fork, one for proof of concept specific repositories, one for a specific type of components, (one for obsolete repositories).
For our current use case this works. However, I can see how managing more than one product would introduce the need for another level of categorization. If we would want to mangage our previous major product version with Phabricator as well we would have yet more projects, and we would not have a grouping of projects belonging to one or the other major version.