Opened 18 years ago

Last modified 3 years ago

#4 new enhancement

Select the branches to display

Reported by: anonymous Owned by: Thomas Moschny
Priority: major Component: tracmtn
Version: 0.0.5 Keywords: <Key>
Cc: <Default>

Description

Hi, I just installed TracMonotone and the source browser is still very much tied, by design, to Subversion. It does not know about branches, and thinks there is but one top-level directory. We both know that there are as many top-level directories as there are branches. Is there an option (perhaps somewhere under trac.mtn.* in trac.ini) that allows me to select the branches in the database that are relevant to a project?

Change History (7)

comment:1 by Ludovic Brenta <ludovic@…>, 18 years ago

Adding my name and email, trac seems to have deleted it between "preview" and "submit".

-- Ludovic Brenta <ludovic@…>

comment:2 by Thomas Moschny, 18 years ago

Type: defectenhancement

Please clarify what you mean by "select the branches in the database that are relevant to a project". Are you referring to the timeline, or the browser?

Note that starting with 0.11, the browser has a quickjump drop-down box for directly jumping to the head of a branch. You can also use the branch:foo.bar syntax for referencing the latest changeset on a branch.

Also it is not clear to me whether creating a virtual root and putting all branches in separate subdirectories of that virtual root is the right thing to do. What about revisions present in more than one branch, and what about revisions not carrying a branch cert at all?

comment:3 by Ludovic Brenta <ludovic@…>, 18 years ago

The current situation for the TracMonotone on Ada-France (http://www.ada-france.org:8080) is that there is a single database containing many projects; each project has its own root directory and consists of one or more branches. Trac, with its Subversion root, wrongly assumes that there is only one root directory per repository, and one repository per project.

I would like to set up one Trac project per project, and specify which branches are part of that project. For example, in the project's trac.ini, I would like to be able to say:

[components] tracvc.mtn.branches = org.log4Ada*

This affects both the timeline and the source browser. For example, if you go to the above URL and browse the sources in the Log4Ada project, you will see the root directory of the org.log4Ada branch, but that's only because that branch happens to be the one with the most recent commit. If I commit to, e.g. org.debian.gnat-gps, then the source browser will show these sources instead of the ones for Log4Ada.

From the timeline it is possible to see all commits in all branches and I also think that that's wrong. For now, in the scenario above, it would be the only way for someone interested in Log4Ada to see the Log4Ada sources after somone commits to an unrelated branch.

I Hope this is clearer now.

-- Ludovic Brenta.

in reply to:  2 ; comment:4 by Ludovic Brenta <ludovic@…>, 18 years ago

I'm using Debian's package for Trac 0.10.2. The actual syntax is h:org.log4Ada (I tried it in the "View Revision" entry box in the browser), and that works. Thanks for the hint. But that doesn't invalidate my request, because the browser should, ideally, hide all the branches not related to the current project, and the timeline does not have a branch filter at all. I think that filtering in both the browser and the timeline according to the list of globs in "tracvc.mtn.branches" would be the best.

comment:5 by Ludovic Brenta <ludovic@…>, 18 years ago

Maybe a good idea would be to replace Trac's repository browser with ViewMTN? There would be some interesting integration necessary, e.g. allow hyperlinks from tracker items to revisions in ViewMTN, from checkin comments in ViewMTN to tracker items and wiki pages, etc. But Trac's repository browser is broken at the conceptual level, IMHO, because it is very tied to Subversion's working model. So, repairing the browser would require major surgery. Do you agree?

Just a thought.

--
Ludovic Brenta.

in reply to:  4 comment:6 by Thomas Moschny, 18 years ago

Replying to Ludovic Brenta <ludovic@ludovic-brenta.org>:

because the browser should, ideally, hide all the branches not related to the current project, and the timeline does not have a branch filter at all. I think that filtering in both the browser and the timeline according to the list of globs in "tracvc.mtn.branches" would be the best.

The timeline will probably get some sort of filtering, as soon as trac itself adds infrastructure for that. The browser however, doesn't know anything about branches and I am not sure whether I really should change that.

Filtering according to branches is an expensive operation, because ancestors of revisions on the branch need to be included by the filter too. It is not enough to do filtering based only on a revision's branch certs.

Also, I don't think that there's a problem with current browser behavior. You might be irritated by the fact that calling the browser without an argument simply displays the root of the last revision checked in, on whatever branch it may reside. But, all links within the browser will keep you on the branch or one of it's ancestor branches.

For convenience, 0.11 will show a drop-down list of all branches and tags above the browser, and thus let you quickjump to a specific revision.

And finally, the right solution for your problem is to set up different monotone databases for each trac project and only pull the branches you want to see there into the respective database.

in reply to:  5 comment:7 by Thomas Moschny, 18 years ago

Replying to Ludovic Brenta <ludovic@ludovic-brenta.org>:

Maybe a good idea would be to replace Trac's repository browser with ViewMTN? There would be some interesting integration necessary, e.g. allow hyperlinks from tracker items to revisions in ViewMTN, from checkin comments in ViewMTN to tracker items and wiki pages, etc. But Trac's repository browser is broken at the conceptual level, IMHO, because it is very tied to Subversion's working model. So, repairing the browser would require major surgery. Do you agree?

Yes and no. Trac's browser is not broken. What is currently broken, are the changeset views, as they assume linear history. TracMtn therefore doesn't properly implement the related parts of the versioncontrol api. But this issues will be addressed for 0.12. There are other vcs backends now, and trac will become less tied to subversion.

And I want TracMtn to remain a plugin, and not rewrite large parts of trac.

Note: See TracTickets for help on using tickets.