Resend.. I sent this from the wrong email address before..
---------- Forwarded message ---------- From: Archie Cobbs <[EMAIL PROTECTED]> Date: Jul 12, 2007 9:21 AM Subject: Re: [Svnmerge] [PATCH] preserving mods to renamed files/directories To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [email protected] I'm not sure if this is directly relevant to this issue, but here's a possibly useful idea to help with situations like this.... In the same way that "svn diff" allows you to plug in your own diff(1) command using the "--diff-cmd" flag, why not have add a flag like "--merge-cmd" to svnmerge that allows you to plug in your own merge command ( i.e., it would be used in place of "svn merge")? Then, instead of folding special merge functionality into svnmerge, once could just provide their own "merge" tool that can be plugged into svnmerge. Such a merge tool might better handle the "rename/merge" problem, etc. Just a thought. On 7/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:
>>> On Wed, Jul 11, 2007 at 5:51 pm, in message <[EMAIL PROTECTED] >, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 10/07/2007 5.57, [EMAIL PROTECTED] wrote: > >> This relates to preserving file and revision log comments changes >> across a merge that includes renames. >> [snip] >> ..I added a call to check_for_changes_to_preserve_across_merge(). This >> function, and the functions it depends on, determine from "merge >> ?? dry? run" output whether there are any matching "add/delete" pairs of >> statements (representing renames) about to be applied, and for each of >> those renames, determines from logs what file edits (diffs) and comments >> would be lost due to the merge's deleting that file and replacing it. It >> [snip] > > I'm ? 1 on this patch, because it adds a *lot* of unnecessary complication in > svnmerge.py, just to workaround a bug (or missing feature) in svn. > > I think there is a right place for every feature, and svnmerge.py isn't just > the right place for this one. I can't but agree with Daniel Rall that any > effort in this direction should be aimed at issue #2685, rather than > kludging > svnmerge.py. > > Really, it's not that I'm against having the bug fixed: it hurts me many > times! It's just that to fix the bug, you need to fix issue #2685, not > svnmerge.py. I can't disagree with you. Our internal situation benefits, however, as we now switch from CVS to Subversion, and to a mode of parallel development with many renames and merges. We don't want to lose changes, and this was something feasible in the time available. I did a lot of research and posted to this list for feedback, before starting work on this patch. Past surprise complexities, postponements, and "false peaks" have plagued the project on this general problem since before svn 1.0. We can't wait for #898 (atomic renames) to be fixed, and it's questionable whether anything like #2685 or #2282 (http://subversion.tigris.org/issues/show_bug.cgi?id=2282) will be done soon enough. What will the purpose of svnmerge.py be, after 1.5 is in use? Granted, some things, like --bidirectional checking (last I knew) could still be missing from merge tracking at 1.5.0. But our organization will almost certainly still need svnmerge.py after 1.5.0, with this (kludgy, temporary, useful, documented, well-tested) patch--until a real solution is in place that minimizes our data loss. Now, having a short-term solution in place for our developers, I'm hoping to learn more about the issues around #2282 and #2685 and see what will or can be done in the medium term or sooner. If there are other ideas for better short-term dataloss prevention, I will be grateful to hear them. So I posted in case anyone else could benefit, or correct mistakes in my thinking; thanks for the feedback thus far. > Moreover, I find your variables with names longer than 30 variables totally > unreadable. If you need 30 characters to describe a variable, it's really Yes, my long variable names. You said it well and I'll try to do better. Best regards, -Luke _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
-- __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com -- __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
