Strange behavior with empty svn repositories

[Itamar O <itamarost@…>]

I'm using 0.12dev r9325 on Windows Server 2003, with Subversion 1.6.5 and Python 2.6.4.

Steps to recreate:

• I added 2 repositories and resync'ed them.
• ReposA has 3 revisions, and I defined an empty alias for it.
• ReposB is empty.

The issue:

1. In "browse source" under "Repository Index" ReposB appears but links to ​http://localhost/browser/undefined
2. Following that link gives "Trac Error" with the message "No node undefined at revision 3"

In addition, I'm using the Hebrew locale, yet both the "Trac Error" title and the error message are not translatable…

[Remy Blank]

Ok, minor issue as empty repositories should be infrequent. Thanks for the bug report.

[Carsten Klein <carsten.klein@…>]

you state that

# ReposA has 3 revisions, and I defined an empty alias for it.

• first: how have you managed to assign it an empty alias?
• second:

In "browse source" under "Repository Index" ReposB a

follows first, the empty alias will prevent you from browsing the repository

• but i am sure you menat ReposA, or did you not?

[Carsten Klein <carsten.klein@…>]

-menat +meant ;)

[Itamar O <itamarost@…>]

Replying to Carsten Klein <carsten.klein@…>:

• first: how have you managed to assign it an empty alias?

Simple: In "Add Alias", left "Name" blank, and selected ReposA. It added an alias to ReposA as the "default repository".

• but i am sure you meant ReposA, or did you not?

I meant ReposB. With the alias defined, I could see the top level of ReposA in "Browse Source" under "Default Repository", and below that both ReposA and ReposB are listed under "Repository Index", with *ReposB* (the empty one) causing the described issue.

At the moment, both repositories are not empty, and with the same configuration I can browse both of them fine.

[Carsten Klein <carsten.klein@…>]

I think that the problem lies with the generated link.

Itamar states that

ReposB appears but links to ​http://localhost/browser/undefined

so we should actually prevent empty aliases from being defined.

[Carsten Klein <carsten.klein@…>]

so we should actually prevent empty aliases from being defined.

At least I believe that it would be best to encourage users to define non empty alias names for all of their repositories in a multi repository environment, and that we should get rid of the default repository, which is declared using the empty alias.

The latter, as was shown by Itamar, leads to rather complex bug fixes, I think.

[Carsten Klein <carsten.klein@…>]

Replying to Carsten Klein <carsten.klein@…>:

Looking at the current trunk, i see that

                    if name is not None and alias is not None:
                        db_provider.add_alias(name, alias)
                        add_notice(req, _('The alias "%(name)s" has been '
                                          'added.', name=name))
                        req.redirect(req.href.admin(category, page))
                    add_warning(req, _('Missing arguments to add an '
                                       'alias.'))

there already is a warning about a missing alias or missing name. However, what happens if the name or alias was declared as a sequence of either a single or multiple whitespace?

[Itamar O <itamarost@…>]

Replying to Carsten Klein <carsten.klein@…>:

so we should actually prevent empty aliases from being defined.

<snip> and that we should get rid of the default repository, which is declared using the empty alias.

Isn't the "default repository" necessary for backward compatibility with single-repos?

If it is, I think it should be allowed to define a default repository some how. Maybe not with a blank alias, if it causes issues. Maybe using something like "_default_"?

[Remy Blank]

Replying to Itamar O <itamarost@…>:

If it is, I think it should be allowed to define a default repository some how. Maybe not with a blank alias, if it causes issues. Maybe using something like "_default_"?

You can already use "(default)", but that gets converted to an empty string anyway.

The cause for the original issue was actually something else altogether, and it's fixed in [9990] (aha, approaching 10'000 changesets :).