trac-admin resync stops on copy

[yves@…]

After a 'svn move' I've changed the path in my trac.ini and I did a 'trac-admin resync'. But the resync command synchronzied only 1 revision:

Resyncing repository history… 1 revisions cached. Done.

In fact I have about 500 revisions. For me it looks like the resync command stops on copy. Doing a 'svn log' on my moved project, I get all my 500 revisions.

[Christian Boos]

Your description is a bit terse, so please correct me if I got it wrong.

You had something like that in your trac.ini:

[trac]
repository_dir = /path/to/repos/myproject

Then you did svn move myproject anothername and changed the repository_dir accordingly (/path/to/repos/anothername). At that point, the resync didn't work…

That doesn't surprise me, the "scoped repository" model doesn't really support this scenario.

[yves@…]

Yes, that's exactly what I did. We have done a reorganisation of our svn structure. Is there any workaround? Ohterwise we loose our whole history which is not the case on the command line.

[Remy Blank]

The only workaround I can see is not to scope the repository:

[trac]
repository_dir = /path/to/repos

But that's going to change the paths to your files (within Trac), so it may introduce other issues.

[Christian Boos]

Yes, there's no easy workaround, but I have an idea how to fix this. It won't be a small change: instead of an unique scope, we would need a list of (rev,scope), rev being the revision in which the scope was introduced. We would get that list when initializing the SubversionRepository and each usage of the scope would require to call a for finding the appropriate value of the scope given the rev we're aiming at.

No promise when/if it can be done, but I'd like to give it a try.

[Christian Boos]

Replying to cboos:

… instead of an unique scope, we would need a list of (rev,scope), rev being the revision in which the scope was introduced.

Note: use SubversionNode.get_copy_ancestry introduced in r8332 for that.

[Remy Blank]

Should this block 0.12?

[Christian Boos]

Definitely not. It would require a good deal of rewrite of the internals of svn_fs.py, but I think without any API change.

[Christian Boos]

See #3470.