code browser is not very linkable

The good news is that there is a nicer url that works already:

http://codebrowse.launchpad.net/~andywingo/guile-cairo/trunk/annotate/46/README

The bad thing is that there's absolutely no way for you to have known this :(

I think Michael meant to give think URL:

http://codebrowse.launchpad.net/~andywingo/guile-cairo/trunk/annotate/head:/README

i.e. "head:" as the revision.

(And also he's linking via filename, "/README", rather than file ID, "?file-id=....")

So Michael, how about a LinkingCodebrowse page on help.launchpad.net?

I wrote a question https://answers.edge.launchpad.net/launchpad-bazaar/+question/45058/ with the main motivation of allowing serving raw files in a usable directory structure. The improvement of the abstract_paths branch offers a solution to the problem.

For example the following would work with the trunk code:

http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/annotate/head:/loggerhead/apps/branch.py

but the following still not:

http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/dowload/head:/loggerhead/apps/branch.py

It seems that the changes implemented in the other controllers, are still missing in the "download" controller.

I made the following changes to make it work:

http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/revision/245

This includes:

- Making the file path scheme work with "download" similarly how it already works with "annotate", etc.
Adjust the templates for this as well. I believe this is a logical consequence to the file path changes implemented so far.

- I had to use "absolutepath" instead of "path" in loggerhead/templates/inventory.pt, it seems "path" is a method at that point (which means that passing path serves no purpose and can lead to bugs, so this still should be fixed)

- Finally, I duplicated the "download" controller as "raw". "download" server the files in a way that the user is offered to download and save them, this is not good for my use case. "raw" is exactly like "download" except it does not include the attachment header in the response, so as a result the browser will visit the file directly instead of offering it to save. The duplication allows "download" keep on working as currently.

So with this changes the raw file would be visited this way for direct browsing:

http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/dowload/head:/loggerhead/apps/branch.py

Of course this would be demonstrated best with a repository containing a static html page, (sphinx documentation, or static mockup). I experimented locally with such examples, but I have no code currently in launchpad to show as a better demo than the above examples.

Please let me know your opinion.

p.s. I made a few errors in the links above, let me correct myself (I made a typo in download and missed to change the last example to "raw":

...

For example the following would work with the trunk code:

http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/annotate/head:/loggerhead/apps/branch.py

but the following still not:

http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/download/head:/loggerhead/apps/branch.py

...

So with these changes the raw file would be visited this way for direct browsing:

http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/raw/head:/loggerhead/apps/branch.py

Should this be fixed in launchpad by now?

For me http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/annotate/head:/loggerhead/apps/branch.py works, but
http://bazaar.launchpad.net/~ree/loggerhead/abstract-paths-fix/raw/head:/loggerhead/apps/branch.py doesn't. I would however like to link to a versioned file and let the browser open the file instead of downloading it to the disk.

I understand where you are coming from, but really this is different from the original bug. I opened bug #605775 to track your needs.