Edgewall Software
Modify

Opened 10 years ago

Closed 9 years ago

Last modified 8 years ago

#586 closed enhancement (fixed)

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

Reported by: hazmat@… Owned by:
Priority: normal Milestone: 0.9
Component: general Version: 0.7.1
Severity: normal Keywords:
Cc: gkokanosky@…, lachlan@…, trapni@…, trac.tickets@…
Release Notes:
API Changes:

Description

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.

Attachments (9)

repo-paths.4.diff (8.8 KB) - added by hazmat@… 10 years ago.
last time .. unified and detabified…
repo-paths.diff (10.2 KB) - added by hazmat@… 10 years ago.
fixes an issue with log and syncs
repo-paths.2.diff (10.2 KB) - added by hazmat@… 10 years ago.
fixes an issue with log and syncs
repo-paths.3.diff (10.2 KB) - added by hazmat@… 10 years ago.
fixes some issues with sync and log, much more tested.
.2 (0 bytes) - added by quannon.au@… 10 years ago.
repos-paths.5.diff (9.3 KB) - added by quannon.au@… 10 years ago.
Modified patch to work with trac-admin for new repositories
repos-paths-trac-admin.5.diff (1.8 KB) - added by quannon.au@… 10 years ago.
Patch for trac-admin to work with repository subset paths
repo-paths.6.diff (10.2 KB) - added by quannon.au@… 10 years ago.
Fix for previous patches breaking log revision file viewing.
repo-paths-trac-admin.6.diff (1.8 KB) - added by quannon.au@… 10 years ago.
Fix for creating regular (no subpath) trac sites

Download all attachments as: .zip

Change History (41)

Changed 10 years ago by hazmat@…

last time .. unified and detabified…

comment:1 Changed 10 years ago by hazmat@…

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

Changed 10 years ago by hazmat@…

fixes an issue with log and syncs

Changed 10 years ago by hazmat@…

fixes an issue with log and syncs

Changed 10 years ago by hazmat@…

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

Changed 10 years ago by quannon.au@…

Changed 10 years ago by quannon.au@…

Modified patch to work with trac-admin for new repositories

Changed 10 years ago by quannon.au@…

Patch for trac-admin to work with repository subset paths

comment:2 Changed 10 years ago by 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.

Changed 10 years ago by quannon.au@…

Fix for previous patches breaking log revision file viewing.

Changed 10 years ago by quannon.au@…

Fix for creating regular (no subpath) trac sites

comment:3 Changed 10 years ago by cmlenz

  • Milestone changed from 0.8 to 0.9

Postponed.

comment:4 Changed 10 years ago by anonymous

Does this patch also work with 0.8?

Thanks Marco

comment:5 Changed 10 years ago by cmlenz

#1037 has been marked as duplicate of this ticket.

comment:6 Changed 10 years ago by anonymous

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

comment:7 Changed 10 years ago by vittorio

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

comment:8 Changed 10 years ago by anonymous

  • Cc manuzhai@… added

comment:9 Changed 10 years ago by 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

comment:10 Changed 10 years ago by Matthew Good <matt-good.net>

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

comment:11 Changed 10 years ago by anonymous

  • Cc mot@… added; manuzhai@… removed

comment:12 Changed 10 years ago by anonymous

  • Cc manuzhai@… added; mot@… removed

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

comment:13 Changed 10 years ago by anonymous

  • Cc mot@… added

comment:14 Changed 10 years ago by anonymous

  • Cc gkokanosky@… added

comment:15 Changed 10 years ago by cmlenz

#1237 has been marked as duplicate of this ticket.

comment:16 Changed 10 years ago by anonymous

  • Cc lachlan@… added

comment:17 Changed 10 years ago by mgood

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

comment:18 Changed 10 years ago by cboos

  • Owner changed from jonas to cboos
  • Status changed from new to assigned

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. ?

comment:19 Changed 10 years ago by cmlenz

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.

comment:20 Changed 10 years ago by cboos

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…

comment:21 Changed 10 years ago by mrowe

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".

comment:22 Changed 10 years ago by cboos

  • Owner cboos deleted
  • Status changed from assigned to new

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:

comment:23 Changed 10 years ago by mgood

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.

comment:24 Changed 10 years ago by anonymous

  • Cc mot@… removed

comment:25 Changed 10 years ago by Christian Parpart <trapni@…>

  • Cc trapni@… added

comment:26 Changed 9 years ago by anonymous

  • Cc trac_ticket.586@… added

comment:27 Changed 9 years ago by anonymous

  • Cc trac_tickets@… added; trac_ticket.586@… removed

comment:28 Changed 9 years ago by jonas

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:29 Changed 9 years ago by Gunnar Wagenknecht <gunnar@…>

  • Cc gunnar@… added

comment:30 Changed 9 years ago by anonymous

  • Cc trac.tickets@… added; trac_tickets@… removed

comment:31 Changed 9 years ago by anonymous

  • Cc manuzhai@… removed

comment:32 Changed 8 years ago by anonymous

  • Cc gunnar@… removed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.