On May 25, 2006, at 1:21 PM, Nico Kadel-Garcia wrote:
> Hold it there: why is renaming a file "trivial"? It's not: every
> reference to that file, anywhere in that software, may have to be
> changed with it. That means there are associated changes with the
> renaming, which the Subversion tracking may not be able to handle
> gracefully: that's especially true with source files.
Having just done this, I can say it's easy to describe the desired
behavior in this case:
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.
As it is, User A must notice that foo.h reappeared, understand why it
happened, and merge changes into bar.h. These are things that the
SVN client knows almost enough to do for him or her. What is lacking
is a distinction between the two separate actions "copy, then delete
the original" and the single action "rename".
Current behavior is perfectly reasonable if we assume that bar.h
is a new file, unrelated to foo.h except for sharing its history.
Once we have a new single action, "rename" we get a new kind of
conflict, where a file is renamed in the working copy, renamed
differently on the repository, and we do an update. Right now
subversion can't distinguish between this case, and the no-conflict
case of two users each intentionally making a separate copy of the
original file.
---------------------------------------------------------------------
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:19:17 2006