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

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

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-10-05 22:10:52 CEST

> -----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
Received on Thu Oct 5 22:11:56 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.