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

Re: Handling of move/rename on merge

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-07-05 16:46:55 CEST

On Mon, 2004-07-05 at 03:15, Tor Ringstad wrote:

> About the behaviour in scenario 2. Wouldn't you consider it
> unfortunate that the modifications to the local file is replaced
> without even a warning? I mean, in practice, this would force users to
> have to manually check every file that was deleted in a merge, first
> to see if it was part of a rename, then to see if there were any local
> modifications that were lost.

There's no lost data here. In your second example, the merge causes the
old name to scheduled for deletion in the working copy and the
newly-named file to appear (as a copy of the earlier version of the
file). But again, that delete operation doesn't lose data. If the file
has local mods, it simply becomes unversioned. If the file has no local
mods, the latest committed change isn't lost: the "newer" text of the
file is still in the repository. Heck, you can even 'svn revert -R' the
result of the merge if you don't like what you get. Merges only produce
local mods anyway.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 5 16:51:11 2004

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.