invalid file links in repos, no-tree unsuported ?

for the last part I RTFM and found
bzr reconfigure [LOCATION]

Options: --bind-to ARG Branch to bind checkout to. --force Perform reconfiguration even if local changes will be lost. --help, -h Show help message. --quiet, -q Only display errors and warnings. --stacked-on ARG Reconfigure a branch to be stacked on another branch. --target_type ARG The type to reconfigure the directory to. --branch Reconfigure to be an unbound branch with no working tree. --checkout Reconfigure to be a bound branch with a working tree. --lightweight-checkout Reconfigure to be a lightweight checkout (with no local history). --standalone Reconfigure to be a standalone branch (i.e. stop using shared repository). --tree Reconfigure to be an unbound branch with a working tree. --use-shared Reconfigure to use a shared repository. --with-no-trees Reconfigure repository to not create working trees on branches by default. --with-trees Reconfigure repository to create working trees on branches by default. --unstacked Reconfigure a branch to be unstacked. This may require copying substantial data into it. --usage Show usage message and options. --verbose, -v Display more information.

See also: branches, checkouts, standalone-trees, working-trees

Reconfigure the type of a bzr directory.

A target configuration must be specified.

For checkouts, the bind-to location will be auto-detected if not specified. The order of preference is 1. For a lightweight checkout, the current bound location. 2. For branches that used to be checkouts, the previously-bound location. 3. The push location. 4. The parent location. If none of these is available, --bind-to must be specified. ;)

trac-bzr operates on the branch level, not the working tree level. Therefore a bare branch without a working tree, as is the default for a --no-trees repositroy, is perfectly all right. I'd even suggest that configuration unless there was some other reason to have working trees around.

The online help section you pasted got pretty messed up with regard to linebreaks, but its --with-trees option is the configuration you were looking for. It only affects new branches, though, so for existing branches a reconfigure --tree would be needed as well. Neither of these should be necessary for tracbzr, though, as stated above.

To analyze your original problem, I'l need more information. Right now, I don't even see where that error message you describe is coming from. So please provide the following information:
- What version of trac are you running?
- What version of trac-bzr are you running?
- What operating system are you on, and if Linux, what distribution and version?
- Did you install trac and trac-bnzr manually or using packages from your distribution?
- Do you have multiple branches in your repository?
- Can you reproduce the problem with a minimalistic branch, or is it specific to some existing branch?
- If this only affects some existing branch, is the information in it confidential or could you mail that?
- Did the page with the error message perhaps contain some python backtrace in its HTML source code?
- Does "bzr cat kb/Makefile" print the file as expected?

thanks for you so prompt answer and my apologies for the poor quality of the report, It was a bit late to do a decent bug report.

Yes I did the -with-trees on the repo and -tree on the branch to get the files back and it did not change the problem at first look so my assumption was wrong and your post confirm that.

for the facts :
- I am on Freebsd 9,
- it is TracBzr-0.4.2 , Bazaar (bzr) 2.5.0
- with a Python interpreter: /usr/local/bin/python2.7 2.7.3.
- I did the installs from eggs in the virtualenv I installed Trac in.
- bzr cat kb/Makefile from the root of the branch works and in the trac-bzr page the two links ("raw text" and "original format") at the bottom of the page are working.
- I do have multiple branches in the repository and even "nested branches" (even if it is not really functionally supported, meaning I have a top branch and another directory beneath it that is also a branch, bazaar, has of now, just ignore the "leaf" branch when doing operation on the "root" branch)

I will clean up/reset the database and limit the number of plug-ins to isolate the problem more precisely.

Thanks a lot again

> I will clean up/reset the database […] to isolate the problem more precisely.

That would be great!

As you talk about all the files being affected by this, I assume that this also affects unnested branches. So perhaps you could create a dummy branch in this way:

$ cd $BZR_REPO
$ bzr init /tmp/dummy
$ mv /tmp/dummy .
$ echo bar > dummy/foo
$ bzr add dummy/foo
$ bzr ci -m baz dummy/foo

trac-bzr does not need its branches to belong to share a single repository, so the above would generate a minimalistic branch, with its own dedicated repository, which you could throw away afterwards. If this works to reproduce the problem, it demonstrates not only that the problem is independent from your specific branch, but also from the data in the associated repository.

> in the trac-bzr page the two links ("raw text" and "original format") at the bottom of the page are working.

Can you please save the generated HTML page and mail it to me? I'm a bit surprised that you have those links, even after an error message, so I assume that I imagine your situation a bit different from what it actually is. It would also be good if you could include the URL of the page in question, at least the part local to this trac environment. Just to make sure what page we are talking about.

Ok fasten your seatbelt this will be a bit long :)

What I did :

I created a new completely isolated virtual env, installed a new Trac and only the trunk version of Trac-Bzr.
I decided to use another method for serving Trac to have more lever to compare and choose to use FCGI.
After many stupid mistakes (no you can't have the same virtual host twice in an apache conf serving different applications, apache will not complain but only load ONE of them but not merge the confs..., ) I was able to have one running (passing the egg-cache for the VEnv in the fcgi wrapper script).

On a side note, I had one trouble with bzrlib that was not found in that context and I had to install bazaar in the VEnv to make it works. It seems not to be the case with the wsgi way, who is able to pick up the system wide bzr, and this coupled with the trouble I had to pass environment variables to the fcgi script makes me think fcgi does a very thorough isolation job, I definitely need to learn more about the specs of the various serving technologies.

[...]
I'll keep it short because I think I found the circumstance that cause the problem :)

I did what you suggested and it fails in a different same way the message was ['' does not end with u'dummy']
the typical message when I browsed "my repository" was [No node UML/ComReferentiel.vpp at revision 15] where the 15th revision is the last one, the one displayed.

In the log I have " Trac[main] WARNING: HTTPInternalError: 500 Erreur Trac ('' does not end with u'dummy')" and
Trac[main] WARNING: HTTPNotFound: 404 Chemin inconnu (Pas de chemin UML/BinAndBinManagement.jpg à la version 15) means "no path UML/BinAndBinManagement.jpg at revision 15".

I had added the top of the bzr repository as a "old style" repository in my new environment and I did not have the problem.
I then added in the [repository] section the same branch I used in my "old" environment and I had the bug again.
I suspected something in relation with old style / new style repository management but is was not the case.

Here is was I understood :
If I add $BZR_REPO the place where repository proper is stored, I can navigate from there and anything I can reach is ok and works.
If I had a branch that is somewhere under that "root", even one I could have accessed by navigating from the top (like your standalone "dummy" branch you had me insert right under the $BZR_REPO) THEN I have the bug in its various forms.
So I suspect the mapping logic between the "relative branches" and the http resources is faulty and it may have to do with the shared repository or not, I will further try to put a standalone branch in a completely separate path and see what happens.

Ok got it :)

Nothing to do with "repos" as far as I can tell.
But everything to do with "nested branches"

a) create a branch put a file and commit
b) create a directory inside it, put a file and commit
c) "bzr split" the new_directory
d) commit top branch and new branch
e) create a trac repository on the new nested branch
f) navigate the new trac_repos=> bug

I don't think the "split" part is necessary, creating a branch inside the top branch and committing should do the trick.

the "top/container" branch seems not to be affected.

Tell me if you can reproduce it, at worst I can provide you access to a test Trac.

Thanks a lot for your support.

Will try to reproduce this one of these days, but if it really is due to nested branches, then you're on your own: there is (hopefully sufficiently prominent) warning at http://pypi.python.org/pypi/TracBzr#hidden-nested-branches to discourage their use. With the current approach, there is no way I can see to ever make them work. I still have to toy a bit with that multi-repo support Trac 0.12 has, but I doubt they'll support nested repos either.

Ok I did not see that (did not check the Pypi page :()

It is a shame because I truly think nested branches supports is a really usefull tool, but bazaar implements it partially (The implementation was stopped at the inner logic half way years ago) but I hoped that Trac would support the part implemented and at least not inder it.

I'll see how I can reconfigure my project and will report if there are still troubles, but I don't expect it.

Talked too fast :)

I reconfigured the branches as standalone, no nesting, no shenanigans and I still have on every file a message like this
"No node Schémas/AgendaParlementaire/AgendaParlementaire.xsd at revision 2" :(

I am a bit out of ideas to isolate the problem, maybe look into bzr/python versions but it seems a bit hollow to me.

Any luminous idea is welcome ;)

> did not check the Pypi page :(
The content of the pypi page comes from the README file included in the bzr tree as well as the source tarballs.

Which files are still affected by these issues? Can you reproduce this using the dummy branch I suggested in comment #4? If not, are multiple of your own branches affected or is it only one?

Can you rename the branch to avoid the non-ascii name, to see if that plays any role in this?

A look at the HTML error message, together with the full URL, both as I requested in comment #4, might still be useful.

as of now the situation is as this :
If I create directly on the server a standalone branch and add it to bzr-trac it works.

If I push one of my now standalone branches to the server it breaks on every "leaf" (file), with or without non ascii character in the path.

If on such a "non working" tree I use the "time/changeset link", I can navigate AND it works.
For instance this
/tracstable/browser/05_Documentation/02_Conception/Schémas/DossierLegislatif/Actes_Legislatifs/Etape.xsd?rev=17
works
Another example without non-ascii:
tracstable/browser/05_Documentation/kb/make.bat breaks with No node kb/make.bat at revision 4
but this : /tracstable/browser/05_Documentation/05_Documentation/kb/make.bat?rev=4 Works

I will mail you the breaking page HTML and the log in info mode (or debug ?)

thanks a lot martin for your investigation.

Indeed any new file I
add works fine and not the one versionned before the split.

But
reading this "If a directory is renamed (e.g. as a consequence of a bzr
split), and a file within said directory is not modified afterwards", I
had hoped that "touching" the files an committing would do the trick but
it does not seem to be the case.

Does that mean that my branches are
for the moment unusable with bzr-trac ?

Doing a fastexport /
fastimport will not change the problem since the "created_rev property"
would be restored the same right ?

Thanks again for your
investigations on that problem.

Cheers

On Tue, 19 Jun 2012 20:01:16
-0000, Martin von Gagern wrote:

> Your question #200255 on Trac-Bzr
changed:
> https://answers.launchpad.net/trac-bzr/+question/200255 [1]
>

> Linked to bug: #1015281
> https://bugs.launchpad.net/bugs/1015281
[2]
> "Error obtaining porevious_revision for file in renamed
directory"
>
> --
> You received this question notification because
you asked the question.

Links:
------
[1]
https://answers.launchpad.net/trac-bzr/+question/200255
[2]
https://bugs.launchpad.net/bugs/1015281

> Does that mean that my branches are
> for the moment unusable with bzr-trac ?

For the moment, unfortunately yes.

Let me think on this for a brief while; I have an idea for a fix but
will need some more time (a few days) to see if I can make it work.