Stefan Sperling <s...@elego.de> writes: > Philip indicated yesterday on IRC that all local move features > he wanted to get to implemented for 1.8 now have code written. > So now we're all waiting for the "local moves" yellow light on > roadmap.html to turn green.
On IRC I stated that the major features had *an* implementation but we still need a consensus that the implementation is fit for purpose. > I think now is the time where we should either start cutting 1.8 alpha > releases from trunk, or branch 1.8 and then start issuing alpha releases > from the branch. I don't think we are ready to branch yet. There are various things that need attention, the major ones are the UI and finite depth updates. The way move-update works is that an update that attempts to change a move source raises move-away-edit tree-conflicts on the move source. The user resolves those conflicts to transfer the changes to the move destination. The process of transfering the changes may raise further move-away-edit conflicts if there are nested moves, and the user resolves those in turn. So to fully update a move the user must keep choosing 'mine-conflict' until all the move-away-edit conflicts are resolved. The problem is that other conflicts can be raised: text-conflicts, property-conflicts and tree-conflicts like delete-edit. The user may not want, or even be able, to resolve these as 'mine-conflict'. So in practice the user has to make a decision on each conflict. In most cases I suspect what the user want is a: resolve all move-away-edit as mine-conflict and leave all the others option. To further complicate the UI it is possible to have moves inside deletes, and moves inside deletes inside moves. The move-update code handles these and can still transfer the changes to the move destination but doing it involves resolving the delete-edit tree-conflicts as 'working. So now I suspect what the user wants is a: resolve all move-away-edit as mine-conflict and all delete-edit as working and leave all the others option. How do we make the UI work? Another thing that needs thought is finite updates. The move-update code requires the move source to be single revision (and no subtree switches). This is fine most of the time, the move source can only be committed when it is equivalent to HEAD so mixed revisions are not that useful. The problem is that various things can make the move source temporarily mixed-rev: an interrupted revision or an explicit update of only part of the deleted tree. Command line users probably don't do finite updates very often but I think it is more common for GUI users to do so. When such an update happens a move-away-edit tree-conflict is raised but now it cannot be resolved as 'mine-conflict' to transfer the changes to the move destination as the move source is not suitable. At present the user's only option is 'working' which breaks the move into a copy and delete. What the user probably wants is to be able to fix the move source so that the 'mine-conflict' option is possible. That involves allowing the user to run update/switch on the root of the move while the move-away-edit tree-conflict is present. I think it would work but it is not currently supported. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
