[Svnmerge] How does SVN handle merging renamed / moved files from "branches"

[Renzo Lazzarato]

At Linkedin we switched form CVS to SVN recently. I would say SVN is
definitely better for us and for sure better than CVS.
We have lot (20+) of actives branches, with several small teams working in
parallel using Agile/Xp methodology and the cost of branching/tagging in SVN
is negleglible (was a pain in CVS)
We are using SVN 1.4. We decided not to use svnmerge.py and instead waiting
for 1.5
We do a lot of re factoring and merging - so we hit the renamed/moved files
problem often

There is a problem with the current SVN implementation you might want to
check out
http://subversion.tigris.org/issues/show_bug.cgi?id=898

There is a nice PPT presentation explaining the scenarios you want to avoid
http://subversion.tigris.org/nonav/issues/showattachment.cgi/729/Subversion%201.4%20true%20renames%20problems.ppt

I hope this help

Renzo








On Feb 5, 2008 9:50 AM, Raman Gupta <rocketraman at fastmail.fm> wrote:

> Eric B. wrote:
> > Hi,
> >
> > Please forgive my incorrect terminology.  I am a CVS user and looking
> into
> > SVN.  One of the things that I find extremely lacking in CVS is the
> ability
> > to move and rename files.  Although CVS has some support for file
> rename, it
> > provides no support for merging renamed files from a branch.
>
> Things are definitely better in svn-land, but far from perfect.
>
> > I appologize if this is not the right place to ask this, but I figure a
> > merge list would be the right place.  I'm trying to understand how SVN
> > handles the case when a file is renamed or moved in a revision (or CVS
> > equivalent to a branch) and then merged back into it's parent rev (or in
> > CVS, the trunk or its parent branch).  Will the renamed/moved file be
> > carried through the merge?  ie: post-merge, which filename will appear -
> the
> > original one or the renamed/moved one?  Is there any "warning" given to
> the
> > user that such a rename/move has occured during the merge?
>
> Svn (and therefore svnmerge.py) does not yet support "true" renames --
> rather, a rename in svn is a "copy" and then a "delete" (though the
> two operations are atomic).
>
> Therefore, when a rename on a branch is merged to the parent, svn (and
> svnmerge.py) will apply the same two operations on the parent: a
> "copy" of the original file to the renamed file, and then a "delete"
> of the original. In some cases this will be sufficient, in other cases
> it may result in lost information if the user is not careful, and in
> still others it may result in a conflict which the user must resolve.
>
> There was some discussion back in May about patching svnmerge.py to
> handle some of these cases [1], however I'm not sure where that ended up.
>
> [1] http://www.orcaware.com/pipermail/svnmerge/2007-May/000913.html
>
> Note that the forthcoming svn 1.5, while still not having true
> renames, as far as I know does have better support for merging
> operations involving renames. This better support translates to
> reducing the number of use cases that "may result in lost information".
>
> For more information and links, see the section "Handle Renames" at
> this URL:
>
> http://subversion.tigris.org/merge-tracking/requirements.html
>
> > Thanks for the information!  If I should be posting this question
> elsewhere,
> > please let me know.
>
> You could also ask on the svn user list if there is anything you are
> still unclear about.
>
> Cheers,
> Raman Gupta
>
> _______________________________________________
> Svnmerge mailing list
> Svnmerge at orcaware.com
> http://www.orcaware.com/mailman/listinfo/svnmerge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/svnmerge/attachments/20080205/d9f405b2/attachment.html>