Stefan Sperling <stsp_at_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
Received on 2013-02-15 14:13:37 CET