Multiple shared repositories confuses trac-bzr

[Russ Brown]

Our trac-bzr install points to a plain directory which contains several shared repositories.

In each of these shared repositories are a number of related branches.

We have been encountering a problem whereby a link to a file in the browser does not work. The error we get is like this:

No node path_to_directory at revision branch_nick,66

Knowing that the file in question *does* exist in the branch, I removed directory levels from the end of the URL given, and got the same error until reaching the branch directory itself. At that point, the error changed to this:

NoSuchRevision: KnitPackRepository('file:///path_to_shared_repo/.bzr/repository/') has no revision <email address hidden>

With this traceback:

2008-09-04 14:36:29,248 Trac[main] ERROR: KnitPackRepository('file:///path_to_shared_repo/.bzr/repository/') has no revision <email address hidden>
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 423, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 197, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.5/site-packages/trac/versioncontrol/web_ui/browser.py", line 343, in process_request
    node = get_existing_node(req, repos, path, rev_or_latest)
  File "/usr/lib/python2.5/site-packages/trac/versioncontrol/web_ui/util.py", line 58, in get_existing_node
    return repos.get_node(path, rev)
  File "build/bdist.linux-i686/egg/tracbzr/backend.py", line 356, in get_node
    return klass(self, branch, tree, entry, path)
  File "build/bdist.linux-i686/egg/tracbzr/backend.py", line 809, in __init__
    ancestry = self.repo.get_ancestry(revisiontree.get_revision_id())
  File "<string>", line 4, in get_ancestry_read_locked
  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1687, in get_ancestry
    raise errors.NoSuchRevision(self, revision_id)
NoSuchRevision: KnitPackRepository('file:///path_to_shared_repo/.bzr/repository/') has no revision <email address hidden>

I've done a little digging, and found that the revision specified by the error is indeed not in the shared repository in question, but is in fact in one of the other ones that our trac-bzr install is serving.

It seems that the revision is being cached somewhere and used in the wrong context.

[Dexter Tad-y (dexterbt1)]

+1 to this.

I have a similar setup, two different branches exposed under a plain directory. I tried to temporarily solve the issue by bumping the revision, which did work at first. I was able to temporarily view the revisions of the branch, until a time came when the error shows up.

A branch though is still accessible by clicking the link under "Rev" column (e.g. "http://host/project/browser/branchA?rev=branchA,1234") , which gives you direct access to the exact revision number. On the other hand, the direct link to the branch via the browser view column "Name" raises the said error (e.g. "http://host/project/browser/branchA")

[Stuart Colville (muffinresearch)]

I have a similar problem using trunk trac-bzr r49 + bzr 1.6.1 + trac 0.10.4-2

In my case trac-bzr is pointed at a single shared repo containing many branches the majority of which are within plain directories.

Clicking through to some of the branches shows the details of one of the other branches rather than the one it should be.

A workaround to be able to view all of the branches is to set the "view revision" box to "current:" however, this can display errors when you try and click on specific revs like so which seems to be related to #263300

Traceback (most recent call last):
  File "/var/lib/python-support/python2.5/trac/web/main.py", line 406, in dispatch_request
    dispatcher.dispatch(req)
  File "/var/lib/python-support/python2.5/trac/web/main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "/var/lib/python-support/python2.5/trac/versioncontrol/web_ui/log.py", line 112, in process_request
    for old_path, old_rev, old_chg in history(limit+1):
  File "build/bdist.linux-i686/egg/tracbzr/backend.py", line 737, in <genexpr>
    return (y for x, y in izip(range(limit), history_iter))
  File "build/bdist.linux-i686/egg/tracbzr/backend.py", line 742, in _get_history
    history = list(self._merging_history())
  File "build/bdist.linux-i686/egg/tracbzr/backend.py", line 701, in _merging_history
    weave = self.tree._get_weave(self.entry.file_id)
AttributeError: 'RevisionTree' object has no attribute '_get_weave'

[Jelmer Vernooij (jelmer)]

We should probably give a better error message here, but I think supporting more repositories is pointless; it just complicates the trac-bzr codebase and hurts performance.

Likewise, trac itself doesn't support more than one repository either. If it would be useful to support more than one VCS instance, the support for that should be in trac imho.

[Russ Brown (pickscrape)]

Pointless? That's quite strong, especially as it basically translates to saying that we can't use trac-bzr.

As far as trac is concerned, a bzr repository is identified by a path. Why should it matter to trac itself if that path happens to point to a directory that contains other repositories? At the end of the day it still contains paths, or is there something I'm missing?

[Jelmer Vernooij (jelmer)]

Why can you not use a shared repository ? You can still have multiple branches without problems.

You seem to be confusing branches with repositories.

[Russ Brown (pickscrape)]

We are using shared repositories already. Our codebase is split into several distinct repositories, each with its own set of branches.

One of the reasons for this is that many of these repositories contain legacy systems that are in the process of being replaced in other repositories. Once the migrations are complete we don't want the old baggage hanging around in the repository of the 'newer' repositories.

This is primarily a concern to the clients though: we previously had nightmare 13G svk depots to deal with. While bzr is vastly more space efficient than svk, we are still well aware of how immutable history cannot be got rid of, hence this separation.

I wonder if it would be possible to use one monolithic shared repository on the server though, with the clients using the separate ones they are now. The repository would contain a number of completely separate trees of history. Would the clients know any different? I'm assuming that the revids wouldn't change, so maybe they wouldn't.

[Jelmer Vernooij (jelmer)]

Yes, there is no relation between the repository layout on the server and on the client. It should work transparently.

[Jack Moffitt (metajack)]

I've been digging into this a bit. I'm not done, but I thought I'd post a little bit about what I found so far. Basically, when Trac wants to show you the HEAD of some directory, it asks for the most recent revision in the repository. This is going to be the most recent in all the sub-repositories combined. If you then try to get the ancestry of a specific branch that isn't from the same sub-repository as this 'youngest' revision, you'll get this error.

I'm still looking to see if this can be fixed somehow so that sub-repositories can still be used. If this is not fixable without huge hacks, I think the solution is to disallow this sub-repository type configuration instead of being so loose with what the Trac repository can be pointed at for bzr.

[Jack Moffitt (metajack)]

I was also able to get a similar problem using just a single repository located at the Trac repo directory (ie, trac points directly at the bzr repository created with init-repo). In it are two branches. If I commit to branchA, the commit to branchB, youngest_rev will point to branchB when I am viewing branchA. Currently this means that I see branchB's file list when viewing the /browser/branchA url. The revision also shows up incorrectly, and I get an exception if I actually try to view any of the branchB files from this location (as expected).

So even with a single repository, this is not working.

If you just throw a collection of branches into an normal directory and point Trac to that, you get the same behavior as if there were multiple repositories. Ie, you get the initial exception reported here.

Unless I'm missing something, it looks like it is not possible to use multiple branches with trac-bzr at all.

Trac does not give the plugin any context when it asks for the youngest revision. The only thing I can think of at the moment is to always return 'current:' as the youngest_rev, regardless of whether we are in an unversioned directory or not.

[Jack Moffitt (metajack)]

Here's a patch which makes get_youngest_rev() always return 'current:'. This seems to make the plugin work correctly in all the cases described in my previous comment.

I looked around in the trac.versioncontrol.* code for references to youngest_rev, and it looks like passing 'current:' should cause no problems. I encountered none during my brief bit of testing.

[Philip Walls (ubuntu-rabidgeek)]

Another +1 on this bug. Jack's patch works for me, and also seems to fix #303327 (which is closely related to this one).

The only problem the patch doesn't resolve is that after you click on a revision, Trac appends ?rev=xxx to all of the links it generates, which prevents you from looking at other branches from that point forward (unless you remove the query string manually).

[Alexander Belchenko (bialix)]

+1. After upgrade to trac-bzr revno.50 I've got this nasty error. trac-bzr revno.34 + bzr 1.5 works without any problem! Bug duplicate: https://bugs.launchpad.net/trac-bzr/+bug/311722

[Alexander Belchenko (bialix)]

Jelmer wrote: "but I think supporting more repositories is pointless; it just complicates the trac-bzr codebase and hurts performance"

Jelmer, this is wrong point of view. It have been worked in previous versions of trac-bzr, and now it does not work.

I have numbers that clearly shows that using multiple shared repos for very big project with multiple separate components in fact *helps* performance, not hurts it.

So "Low" importance for this bug is wrong IMO. Of course you're choose it, but looks how many people affected by this bug. It's not minor bug. It's very serious regression.

[Paul Brossier (piem)]

fyi, on debian lenny lp:~jlgeering/trac-bzr/experimental fixes this bug

ii bzr 1.16.1-1~bpo50+1
ii trac 0.11.5-4~bpo50+1

cheers, piem

[Yung-Chin Oei (yungchin)]

Thanks Piem. In fact, I just tried, and this seems not to be a problem anymore with trac-bzr's current mainline on launchpad, rev69, either. I hope this bug-status change makes sense...

[Martin von Gagern (gagern)]

Should be included in the 0.3.0 release, whatever the actual fix was.