patch to allow trac to operate on repository subset for multi project repositories

[hazmat@…]

to use trac with a multi-project repository, i needed trac to be able to browse and operate only on a repository subpath, this also includes some changeset filtering functionality. i've attached the patch needed for this to happen, done against 0.7.1.

some concerns about the patch, while its fairly clean overall, the fact that sync is done implicitly on every svn module usage means that the changed revisions for a particular path are retrieved automatically for each revision. which can be expensive on repositories with thousands of commits. there isn't much alternative if this sort of implicit work is done, else the db will be filled with lots of empty revisions which are not applicable. requiring use of a contrib cron job to achieve explicit syncing would solve this issue.

[hazmat@…]

last time .. unified and detabified…

[hazmat@…]

sorry about the massive number of uploads.. having reality check issues. the last version repo-paths.4.diff is the good one.

[hazmat@…]

fixes an issue with log and syncs

[hazmat@…]

fixes an issue with log and syncs

[hazmat@…]

fixes some issues with sync and log, much more tested.

[quannon.au@…]

Modified patch to work with trac-admin for new repositories

[quannon.au@…]

Patch for trac-admin to work with repository subset paths

[quannon.au@…]

Some slight modifications so that trac-admin can be used to make new repositories using this patch. User is queried during initenv for a repository_path to be placed in the config file.

[quannon.au@…]

Fix for previous patches breaking log revision file viewing.

[quannon.au@…]

Fix for creating regular (no subpath) trac sites

[Christopher Lenz]

Postponed.

[anonymous]

Does this patch also work with 0.8?

Thanks Marco

[Christopher Lenz]

#1037 has been marked as duplicate of this ticket.

[anonymous]

I'd like for this patch to be in 0.9.

[vittorio]

#1059 has been marked as a duplicate of this ticket.

[anonymous]

The patches provided don't work out of the box vs 0.8, quite a lot of manual messing about required.

Some issues I've found:

• The trac-admin patch should also affect resync (with the stock patch it barfs on sync())
• for some reason file browsing isn't working, I'm getting a spurious 'a' component in the url path for files (<hostname>/<project>/browser/a/<path>)
• adding the project which contains the youngest revision causes a "Reference to non-existent revision" exception in trac-admin

Simon

[Matthew Good <matt-good.net>]

#1082 has been marked as a duplicate of this ticket.

[anonymous]

ah, sorry. thought cc would add me to a cc list, not change it.

[Christopher Lenz]

#1237 has been marked as duplicate of this ticket.

[Matthew Good]

#1398 has been marked as a duplicate of this ticket.

[Christian Boos]

I also have astrong interest on that topic, because our main Trac environment is based upon one big Subversion repository, which, in the short term, will contain all the code for all our projects (which is a good thing because we have a lot of shared components).

It will soon be a requirement to provide our developers with an easy way to filter the components in which they are interested in. That would typically be 1 or 2 applications, and several common libraries.

I have some ideas about how to implement this feature. This would require the relationship facility found in the trac-obj branch.

The heart of the solution would be based on Component pages, which are wiki page that have a is-a relation to the ComponentTemplate page (i.e. the page was created using that template, see #1376).

That page would be related to specific Source objects (directories or files, see changeset:1486#file1) that will be used to filter in the changesets affecting this component.

Additionally, those component pages will also be used to populate the Component: field for tickets.

The list of those pages could be attached in some ways to the developer:

1. by relationships created between the developer pages and the component pages?
2. by use of the settings?
3. by a multiselection filter on the timeline?

The first solution would create some interesting "intelligence" about the software infrastructure (i.e. one can image queries like who works on what?) but is maybe less flexible than 3. Maybe the ideal solution would be 1. + 3., the default selection for 3. would be given by 1. ?

[Christopher Lenz]

cboos, this ticket is about supporting Trac to work with a subset of the repository. I don't see what this has to do with components, component-developer relation-ships, or pretty much anything else mentioned in your last comment.

As a matter of fact, we already have some support for repository subsets as of [1413]. I.e., instead of having to specify the base path of the repository in TracIni, you can specify a path inside the repos (for example /var/svn/myrepos/project/subproejct, where /var/svn/myrepos is the path to the repository).

One limitation of the support is that the chosen subset of the repos needs to be fully self-contained, i.e. may not contain resources copied/moved from other parts of the repository.

If you are interested in supporting repository subsets, I suggest you test that support and maybe try to improve it where necessary.

[Christian Boos]

Well, I guess you consider that one Trac environment should support only one subset of the repository, right?

Maybe my comments above can be better understood if I make clear that I think that one Trac environment should be able to support multiple subsets.

Of course, that's highly dependend on the usage scenario. In favor of the one Trac environment / several project subsets:

• only one Wiki namespace, therefore better knowledge sharing between teams
• shared milestones, corresponding to coordinated software release affecting multiple projects
• bugs/enhancements that affect multiple projects

With this in mind, I think the approach proposed above makes sense, as one would need the appropriate mix of structure and flexibility to manage that effectively.

Maybe the approach I advocate is closer to #1135, so maybe one could rename that ticket to patch to allow trac to operate on one repository subset for multi-project repositories, you close it when you think that the support introduced in [1413] is ok, and I'll go on with this approach elsewhere…

[Mark Rowe]

cboos, as far as I can tell all of the points that you have made are completely orthogonal to the issue that this ticket raises — that a Trac environment should be able to work on a specified subset of a repository. The changeset that cmlenz mentioned goes a long way to providing this support. More testing is needed, and perhaps some extra thought should be put into the edge cases (What is the best behaviour with regards to copies from outside the subset?, etc)

As for your suggestion, I am at a loss how this relates to Wiki pages, templates and components (??). It smells to me of over-engineering, and I am afraid that the approach you mention will be overly complex and against Trac's ideal of using "a minimalistic approach to web-based software project management". I think that we should "​Do The Simplest Thing That Could Possibly Work".

[Christian Boos]

Ok, I think I understand now. Actually, there are two approaches and two set of tickets about multiple project support. I've written a kind of synthesis in:

• TracMultipleProjects/SingleEnvironment
• TracMultipleProjects/MultipleEnvironments

[Matthew Good]

Besides the copy/move issues, is there anything outstanding on this ticket that needs addressed? I think that this ticket can be closed, and open a new ticket for the copy/move stuff.

[Jonas Borgström]

I agree with your mgood, I've opened a new ticket (#1830) and will close this ticket now.