Page MenuHomePhabricator

Support for grouping Diffusion repositories in UI
Closed, ResolvedPublic

Description

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

Event Timeline

hach-que added a project: Diffusion.
hach-que added a subscriber: hach-que.
hach-que edited this Maniphest Task.May 4 2013, 3:53 PM
epriestley triaged this task as Low priority.May 4 2013, 4:58 PM

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.

+1 for wanting this.

avivey added a subscriber: avivey.Jul 18 2013, 10:01 PM

@avivey, can you describe your use case a bit? So far we have two (Facebook and @hach-que) and they're very different.

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.

(sorted by title; just realized that)

brent added a subscriber: brent.Oct 13 2013, 8:45 AM

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.

◀ Merged tasks: T3935.

To summarize T3935, the path forward here looks like:

  • Implement Project/Repository relationships, see if that solves the problem.
  • If it's still an issue, look at refining things.
epriestley changed the visibility from "All Users" to "Public (No Login Required)".Nov 22 2013, 9:58 PM

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.

T4103 covers configuring default search views.

epriestley edited this Maniphest Task.Jan 3 2014, 1:19 AM
epriestley edited this Maniphest Task.Jan 3 2014, 8:24 PM
avivey edited this Maniphest Task.Jan 30 2014, 7:42 PM
avivey edited this Maniphest Task.Jan 30 2014, 7:46 PM
avivey edited this Maniphest Task.Jan 30 2014, 8:37 PM

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.

  • Implement Project/Repository relationships

See https://git.wikimedia.org/projects for an example (in gitblit) of what's needed. (Can this be added to Wikimedia tasks here?)

chad renamed this task from Support for grouping Diffusion repositories in UI. to Support for grouping Diffusion repositories in UI.May 19 2015, 3:12 PM
hach-que closed this task as Resolved.May 19 2015, 6:19 PM

With both saved search and project tagging, this is reasonably solved.