[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with multiple users moving and updating files

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-05-25 20:21:54 CEST

On 5/25/2006 2:17 PM, Adam Aulick wrote:
> 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.

  --- 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.

Duncan Murdoch

>
> 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

---------------------------------------------------------------------
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:23:49 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.