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 <[EMAIL PROTECTED]> 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 > [email protected] > http://www.orcaware.com/mailman/listinfo/svnmerge >
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
