[Svnmerge] [PATCH] preserving mods to renamed files/directories

[lsuvkne at onemodel.org]

>>> On Wed, Jul 11, 2007 at  5:51 pm, in message <46956CE5.1070900 at develer.com>,
Giovanni Bajo <rasky at develer.com> wrote: 
> On 10/07/2007 5.57, lsuvkne at onemodel.org 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