improve handling of scoped repositories with copy history

[posterday@…]

While testing r3015, the revisions are still not working properly. I removed trac 0.9.6, checked out and installed r3570. I ran all the required upgrade commands and resync'd, but trac still always shows one rev for the part of the svn repo moved from another part.

Here's an example… the svn repo had proj1/trunk/java/src and proj2/trunk/websrc. I renamed websrc in proj2/trunk to src. Then I created proj1/trunk/web and moved src from proj2/trunk to proj1/trunk/web. When I make a change to web/src/file1 the revision is incremented, but all files in web/src show that revision too.

If I point trac to the root of the repo and resync, things work better, but if I point to proj1, the revision for the moved code is always the latest revision for files that haven't been updated since the move.

I'm guessing this is because trac is indexing only the current point in the history since the move.

[Christian Boos]

I admit I had to scratch my head a few times to understand the scenario you described… Let me reformulate it:

• When the scope of a repository is set to a path that was created by a move/copy operation, the entries that have not been modified since the move do show a revision identical to the requested one (e.g. head revision if one is browsing the head)
• Instead, one would expect to see there the revision of the copy operation itself.

[Christian Boos]

Ok, so I can't find a fix to this problem for milestone:0.10, as one would really need to have the Repository.get_path_history functionality here, but it would be too costly given its current implementation.

This will have to wait milestone:0.11 and in particular the VcRefactoring#NewRepositoryCache

[Pat Osterday <posterday@…>]

Sorry I wasn't clear on the issue - but I think you got the point. This isn't a show stopper for us, since we can always get the real history using ViewCVS/Subclipse/TortoiseSVN if we need to.

The VcRefactoring stuff looks promising.

My idea was maybe to be able to point trac to the root of the repo, but scope it to a project in the repo. If trac was aware of the whole repo - like /opt/svn/repo, but scoped to /opt/svn/repo/proj1, it would still be aware of /opt/svn/repo/proj2 since that's where the moved code was originally. I'll let you guys hash out the details!

[Christian Boos]

Not for 0.11.

[Christian Boos]

#6624 shows a similar effect:

• scope is /var/svn/aForge (within /var/svn repos)
• /aForge/aFiles was copied from somewhere outside of the scope (log shows it's a copy r54 from "(root)")
• until it aFiles itself will see some changes, it will always reflect the last changeset in the browser, and that looks confusing since it will always be an unrelated path (/aForge/dimdim/trunk/asw in the report)

[Christian Boos]

#7264 describes a similar situation as well.

[Thijs Triemstra <lists@…>]

Can someone rename this ticket..

[Christian Boos]

And with the new summary, the proximity with #8301 is more apparent ;-)

As noted there, using SubversionNode.get_copy_ancestry should help here. The scope should actually follow the copy history of the specified scope, the latter corresponding only to the scoped path at the "latest" revision.

[Christian Boos]

A clean-up of the svn_fs code similar to the one which was recently done for Mercurial could be useful. At this occasion, we could also implement this feature.