Feature #21465
open
Make Redmine Repository module to handle better repositories removed in SCM and avoid not found error
Added by Sebastian Paluch over 8 years ago.
Updated almost 7 years ago.
Description
While working on a project there are development branches that at the end should be removed from SVN to keep SVN clean and readable.
Unfortunately, when a repository is removed from SVN, Redmine displays an error message not allowing to browse what was there before. I do not want to remove repository from Redmine as that would remove all the associated revisions in issues.
Instead of an error I would expect Redmine to show automatically the repository at last known revision or allow to specify in repository settings a revision the repository should be locked to (something instead of HEAD).
Files
I would expect Redmine to show automatically the repository at last known revision
Redmine does not cache the repository content, so if the repository is removed from SVN, there's no way we can make it browseable in Redmine.
We only save changesets in the Redmine database. What we could maybe do is display the changesets list when clicking the Repository tab, instead of a 404.
But SVN itself does allow to browse repository at specified revision. Now Redmine asks SVN to show head revision and if repository is not there it returns error. Instead, in case of error, Redmine could ask SVN to show repository at last known revision number, the number it synchronized to last time avoiding nasty error. There is no need to cache repository content.
Alternatively or additionally Redmine could allow to specify fixed revision number up to which repository is synchronized.
So your SVN repository is not deleted but you have a Redmine repository that is mapped to a branch that was deleted for this repository, right?
Yes, just the path specified as "URL" in Redmine Repository settings does not exists on SVN repository server but the server is still running and hosting correct SVN repository. Sorry for being not precise.
Are there any chances to get this improved? Current implementation breaks traceability when branches are often created and removed :(
I have attached small patch (for 3.3-stable) that fixes the problem. All it does is that in few places where repo is asked for details and fails, it try again with last known revision. I'm not sure if all places are covered but have not found any problems with this yet.
JPL, is there a chance to add this small patch to next release?
Also available in: Atom
PDF
Updated by 
Updated by