shared repository with multiple branches doesn't work

[Philip Walls]

Steps to reproduce:

1) Create a shared repository with multiple branches:

$ bzr init-repo --no-trees /path/to/repo
$ bzr branch <something1> /path/to/repo/<something1>
$ bzr branch <something2> /path/to/repo/<something2>

2) Point trac-bzr at the repository (repository = /path/to/repo)

3) Navigate to the browser and look at both branches

Expected result:

Both "something1" and "something2" branches should be navigable and show the correct files and revision numbers while browsing the branch.

Actual result:

For the sake of this explanation, let's assume that "something1" was the most recently active (committed to) branch.

No matter which branch you navigate to, the contents of the branch with the *most recent revision* (for the sake of this example, "something1") is always the one whose contents are shown.

Another symptom of this problem is when viewing the contents of the something2 branch, all revision ids listed in the "Rev" column of the browser are incorrectly resolved, resulting in revisions like: "pawalls%40rabidgeek.com-20081128235330-6ngjpzgadi6zp29e" instead of the expected "something2,1234".

My memory is kinda hazy, but I looked into the problem a bit earlier. Take this with a grain of salt, but based on what I can recall:

- Trac calls get_youngest_revision() in trac-bzr which returns ("something1", "something1,1234")
- Trac then calls get_node() with the original request branch ("something2") and the youngest revision ("something1,1234")
- trac-bzr turns the result into a string using string_rev() which fails to find such a revision in "something2", so it returns the bzr hashed revision.
- this string is used by Trac later to derive the string to show in the Rev column
- get_node() calls get_containing_branch() with these arguments, which returns the wrong branch

Workaround:

You can view the branch correctly if you append "?rev=current:" to the Trac URL produced by the browser.

[Ross Light (quartz25)]

I have pushed a branch that might be able to fix this problem. I don't know if it is the most correct way to fix the problem, but it seems to fix the problem on my installation.

[Forest Bond (forest-bond)]

I'm seeing this with trac 0.11 and bzr 1.3.1.

Would it make sense for get_youngest_revision to simply return "current:"?

Thanks,
Forest

[Forest Bond (forest-bond)]

Oh, I see that that's what your branch does, Ross.

Can a trac-bzr developer comment on this fix?

Thanks,
Forest

[.:. brainsik (brainsik)]

When I merge this branch into the main trac-bzr branch, I get the bug where "current:" shows up as a permanently recent checkin in the timeline:

https://bugs.launchpad.net/trac-bzr/+bug/116659

Otherwise, it works great! Is there a way of changing the code so it works without producing that "phantom changeset"?

[Ross Light (quartz25)]

I am aware of the phantom changeset bug, but I'm not sure how much can be done without changing Trac.

It seems as though the offending code to patch is in "trac/versioncontrol/web_ui/changeset.py", in the ChangesetModule.get_timeline_events method. If one could inject a check for the "current:" revision there, then everything would be okay.

I could try to hack this (via assigning the method to another function), but that could break on future versions of Trac, and it seems like it would be more trouble than it's worth.

[.:. brainsik (brainsik)]

The patches on the "Phantom changeset" bug seem to be focussed on giving the "current:" changeset a stable timestamp so it isn't always floating at the top. I don't understand any of this code well enough to know whether those tactics would work with your change. Have you checked them out?

Thanks for replying, it is really appreciated.