> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: dinsdag 12 maart 2013 20:32
> To: Mark Phippard
> Cc: C. Michael Pilato; Philip Martin; Branko Čibej;
> dev_at_subversion.apache.org
> Subject: Re: svn_client_move7 and mixed-revisions
>
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > I don't understand this. You seem to be asking for move tracking to be
> > unreliable in order to avoid a message that tells users how to make move
> > work. When the user moves things around some of the 'moves' will show
> > up as moves and others will not. How is that sensible? How is the user
> > supposed to understand what is happening?
>
> Further, one of the ways users get mixed-revision working copies is by
> committing. If one then moves such a mixed revision and it degrades to
> copy+delete it is not generally possible to commit the 'move' because
> some part of the delete will be out-of-date. If we don't make users
> update before move they often have to run update before comitting. If
> the users have to run update anyway it's far better to get them to do it
> before the move so that move tracking works.
The problem here is that we now require the update before moving. If we can
postpone that requirement to the commit time, there is no problem for
clients like Subclipse and AnkhSVN. A move or copy is an operation that is
performed as part of larger operations, while commits and updates are not.
Those operations are specific to version control.
Moves and copies are often contained in automated tasks like refactoring
tools.
And those refactor tools might change many files, move files, change more
file, move a few more files. And you can't just fail in that last step.
Requiring the user to then perform an update before committing is no
problem. But breaking powerful refactoring tools is.
Bert
Received on 2013-03-12 21:39:17 CET