I'm thinking of patching svnmerge to address the much-discussed (at least on the svn users list) problem of a rename being merged into a working copy with a modified file, losing the modifications (because rename is implemented as add+delete). My basic approach is to check the log for the revision range being merged, and if it contains an Add entry with a "From" where the "From" is the same as a path with a Delete entry, then do a diff to get the changes for the file about to be deleted, and apply them to the newly added file.
I can provide details if that is unclear; it looks like unfortunately it will require the user to have a locally-installed "patch" utility (cygwin or *nix), which I imagine could prevent acceptance of my patch, in which case we'd just use it locally. However, given the number of svn users affected by this problem of data loss, and that it's even documented in the user manual (see http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.moves ), I think this workaround could be useful to many until the actual bug is fixed (http://subversion.tigris.org/issues/show_bug.cgi?id=898). Does anyone see problems with my general approach? If not I'll hopefully submit the actual patch for feedback, later on. Thanks, -Luke Call (ps--more info at the threads around messages linked here: http://subversion.tigris.org/servlets/SearchList?list=users&searchText=yet+better+rename+approach&defaultField=body&Search=Search ). (pps--should I be sending this to the svn dev list?) _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
