Re: Merging renamed files. Bug? Feature Gap? Other?

[Garrett Rooney <ro...@electricjellyfish.net>]

On 10/5/06, Reedick, Andrew <An...@bellsouth.com> wrote:
> This issue came up on
> http://www.cmcrossroads.com/component/option,com_smf/Itemid,180/topic,68
> 423.msg74812#msg74812
>
> Here's the post:
>         "Two parallel branches exist (one may be doing rapid releases,
> the other may be working on a major change that will take a while).  In
> one of the branches, files are refactored and the name of a file is
> changed.  What happens when one stream needs to merge into the other?
> Does the tool know that the two are the same file and merge them, or are
> they considered separate files and not merged?"
>
>
> After a quick test, the answer appears to be 'considered separate files
> and not merged'.  In theory, this means work is lost.
> 1.  Create trunk/foo.txt
> 2.  svn copy trunk branch
> 3.  commit changes to branch/foo.txt
> 4.  commit changes to trunk/foo.txt (to force a merge conflict)
> 5.  ren branch/foo.txt to branch/bar.txt
> 6.  merge from branch to trunk.
>
> In theory, trunk/foo.txt and branch/bar.txt are the same.  (From a
> developer point of view, and from an ancestry point of view.)
>
> In reality, subversion sees them as separate objects, so svn merge will
>       A  bar.txt
>         D  foo.txt
> Since trunk/foo.txt gets deleted, any changes made to trunk/foo.txt are
> lost.  The trunk/foo.txt is not merged with trunk/bar.txt, even though
> foo.txt is the ancestor of bar.txt.
>
> Am I correct in how I stated this?  And is this a bug or a feature?  I'm
> starting to get a queasy feeling about this scenario.  Is it worth
> worrying about?

Yes, you should worry about it.  It's the kind of problem that we want
the ongoing atomic rename support to fix, but unfortunately, those
fixes will be rather far in the future, it's a hard problem to solve,
and there are many steps that need to be taken before it'll be visible
to users.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Merging renamed files. Bug? Feature Gap? Other?

["Reedick, Andrew" <An...@BellSouth.com>]

> -----Original Message-----
> From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of 
> Garrett Rooney
> Sent: Thursday, October 05, 2006 2:10 PM
> To: Reedick, Andrew
> Cc: users@subversion.tigris.org
> Subject: Re: Merging renamed files. Bug? Feature Gap? Other?
> 
> Yes, you should worry about it.  It's the kind of problem that we want
> the ongoing atomic rename support to fix, but unfortunately, those
> fixes will be rather far in the future, it's a hard problem to solve,
> and there are many steps that need to be taken before it'll be visible
> to users.
> 

How about this for a workaround script?  

The renamed object's original path and revision is listed in 'svn log'.

		A /trunk/delta/branch/bar.txt (from
/trunk/delta/branch/foo.txt:223)
It should be possible to analyze the output of 'svn merge', dump the
history of each Added and Deleted file, and check for common ancestors
between the Adds and the Deletes.  If any Add/Delete pair shares
ancestry, then flag it for special attention.
	
Are you aware of flaws in the logic, or special cases that would need to
be considered?  (Meaning is there something I'm not thinking of that
tanks the whole idea?)  Peg revisions, multiple renames and/or directory
renames could make things interesting (or recursive.)  As would the
'delete/create' in a single commit.  I do have some free time coming up
and could work on a script.


Bah, merges would complicate this.  Since a merge can replace the target
file object with the source file object (Evil Twin scenario where 'svn
merge' does a:
	A widget.txt (from branch)
	D widget.txt (trunk))
it might not be possible to be 100% certain of a file's
lineage/ancestry/history.


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org