On May 25, 2006, at 2:21 PM, Duncan Murdoch wrote:
> On 5/25/2006 2:17 PM, Adam Aulick wrote:
>> User A renames a header file foo.h to bar.h (using subversion
>> command) and modifies four dozen source files to match.
>> User B commits modified foo.h
>> User A does an update -- correct behavior is to merge foo.h
>> changes from the repository into bar.h in the working copy.
>
> --- and report a conflict to be resolved by the user ----
>
> It is possible that something B did is incompatible with the
> rename. User A should have to confirm this is not the case before
> committing the rename.
Well, of course, but this is true any time a file is simultaneously
changed in two working copies. It's not any more true in this case.
What I would like to see in the client is a status flag on every file
in the working copy that has been merged (which the user can clear
after manually reviewing the merge) and a new property to indicate
whether files may be committed with the unreviewed-merge flag still
set. The flag is part of the working copy and not sent to the
repository. But that's a separate issue unrelated to file renaming.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 25 20:48:15 2006