Edgewall Software

Opened 15 years ago

Last modified 6 years ago

#3470 new defect

improve handling of scoped repositories with copy history

Reported by: posterday@… Owned by:
Priority: high Milestone: next-major-releases
Component: version control Version: devel
Severity: major Keywords: svn scoped repository
Cc: lists@… Branch:
Release Notes:
API Changes:
Internal Changes:


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.

Attachments (0)

Change History (12)

comment:1 by Emmanuel Blot, 15 years ago

Milestone: 0.10

comment:2 by Christian Boos, 15 years ago

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.

comment:3 by Christian Boos, 15 years ago

Milestone: 0.11

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

comment:4 by Pat Osterday <posterday@…>, 15 years ago

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!

comment:5 by Christian Boos, 15 years ago

Milestone: 0.110.12

Not for 0.11.

comment:6 by Christian Boos, 14 years ago

#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)

comment:7 by Christian Boos, 13 years ago

#7264 describes a similar situation as well.

comment:8 by Christian Boos, 11 years ago

Priority: highlow
Severity: normalmajor

comment:9 by Thijs Triemstra <lists@…>, 11 years ago

Cc: lists@… added

Can someone rename this ticket..

comment:10 by Christian Boos, 11 years ago

Keywords: repository added
Summary: r3015 didn't fix my repo move problemimprove handling of scoped repositories with copy history

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.

comment:11 by Christian Boos, 11 years ago

Priority: lowhigh

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.

comment:12 by Ryan J Ollos, 6 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.