Edgewall Software
Modify

Opened 20 years ago

Closed 19 years ago

Last modified 18 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@… Branch:
Release Notes:
API Changes:
Internal 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@… 20 years ago.
last time .. unified and detabified…
repo-paths.diff (10.2 KB ) - added by hazmat@… 20 years ago.
fixes an issue with log and syncs
repo-paths.2.diff (10.2 KB ) - added by hazmat@… 20 years ago.
fixes an issue with log and syncs
repo-paths.3.diff (10.2 KB ) - added by hazmat@… 20 years ago.
fixes some issues with sync and log, much more tested.
.2 (0 bytes ) - added by quannon.au@… 20 years ago.
repos-paths.5.diff (9.3 KB ) - added by quannon.au@… 20 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@… 20 years ago.
Patch for trac-admin to work with repository subset paths
repo-paths.6.diff (10.2 KB ) - added by quannon.au@… 20 years ago.
Fix for previous patches breaking log revision file viewing.
repo-paths-trac-admin.6.diff (1.8 KB ) - added by quannon.au@… 20 years ago.
Fix for creating regular (no subpath) trac sites

Download all attachments as: .zip

Change History (41)

by hazmat@…, 20 years ago

Attachment: repo-paths.4.diff added

last time .. unified and detabified…

comment:1 by hazmat@…, 20 years ago

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

by hazmat@…, 20 years ago

Attachment: repo-paths.diff added

fixes an issue with log and syncs

by hazmat@…, 20 years ago

Attachment: repo-paths.2.diff added

fixes an issue with log and syncs

by hazmat@…, 20 years ago

Attachment: repo-paths.3.diff added

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

by quannon.au@…, 20 years ago

Attachment: .2 added

by quannon.au@…, 20 years ago

Attachment: repos-paths.5.diff added

Modified patch to work with trac-admin for new repositories

by quannon.au@…, 20 years ago

Patch for trac-admin to work with repository subset paths

comment:2 by quannon.au@…, 20 years ago

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.

by quannon.au@…, 20 years ago

Attachment: repo-paths.6.diff added

Fix for previous patches breaking log revision file viewing.

by quannon.au@…, 20 years ago

Fix for creating regular (no subpath) trac sites

comment:3 by Christopher Lenz, 19 years ago

Milestone: 0.80.9

Postponed.

comment:4 by anonymous, 19 years ago

Does this patch also work with 0.8?

Thanks Marco

comment:5 by Christopher Lenz, 19 years ago

#1037 has been marked as duplicate of this ticket.

comment:6 by anonymous, 19 years ago

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

comment:7 by vittorio, 19 years ago

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

comment:8 by anonymous, 19 years ago

Cc: manuzhai@… added

comment:9 by anonymous, 19 years ago

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 by Matthew Good <matt-good.net>, 19 years ago

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

comment:11 by anonymous, 19 years ago

Cc: mot@… added; manuzhai@… removed

comment:12 by anonymous, 19 years ago

Cc: manuzhai@… added; mot@… removed

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

comment:13 by anonymous, 19 years ago

Cc: mot@… added

comment:14 by anonymous, 19 years ago

Cc: gkokanosky@… added

comment:15 by Christopher Lenz, 19 years ago

#1237 has been marked as duplicate of this ticket.

comment:16 by anonymous, 19 years ago

Cc: lachlan@… added

comment:17 by Matthew Good, 19 years ago

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

comment:18 by Christian Boos, 19 years ago

Owner: changed from Jonas Borgström to Christian Boos
Status: newassigned

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 by Christopher Lenz, 19 years ago

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 by Christian Boos, 19 years ago

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 by Mark Rowe, 19 years ago

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 by Christian Boos, 19 years ago

Owner: Christian Boos removed
Status: assignednew

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 by Matthew Good, 19 years ago

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 by anonymous, 19 years ago

Cc: mot@… removed

comment:25 by Christian Parpart <trapni@…>, 19 years ago

Cc: trapni@… added

comment:26 by anonymous, 19 years ago

Cc: trac_ticket.586@… added

comment:27 by anonymous, 19 years ago

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

comment:28 by Jonas Borgström, 19 years ago

Resolution: fixed
Status: newclosed

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

comment:29 by Gunnar Wagenknecht <gunnar@…>, 19 years ago

Cc: gunnar@… added

comment:30 by anonymous, 19 years ago

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

comment:31 by anonymous, 18 years ago

Cc: manuzhai@… removed

comment:32 by anonymous, 18 years ago

Cc: gunnar@… removed

Modify Ticket

Change Properties
Set your email in Preferences
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.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.