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

[Daniel Rall]

On Thu, 21 Jun 2007, lsuvkne at onemodel.org wrote:

> >>> On Thu, Jun 21, 2007, Daniel Rall <dlr at collab.net> wrote: 
> > The some (all?) of the failures were introduced by Blair's commit of
> > some code to svnmerge.py, without any corresponding changes to
> > svnmerge_tests.py.  While I haven't investigated, I'd guess that the
> > tests need to be updated, since IIRC, Blair's commits were (all?) 
> > intended as bug fixes.
> 
> Do you recall the approximate month, say, of those changes? If it seems likely
> (with mods as per Dustin's suggestions) that the rest of my patch (or a
> subset) will be useful to others, I will go ahead & try to fix those other 3
> failing tests as well, but I'd like to look up what changes caused them.

To determine this information, I'd previously looked back through the
history of svnmerge.py, found a likely range in which I thought the
breakage might've been introduced, then did a binary search through
revisions in that range to determine the exact culprit (r22788).

I quick search of the Orcaware list archive shows my original post on
the topic:
http://www.orcaware.com/pipermail/svnmerge/2007-January/000821.html

Fixing these broken tests would be a great starting point for making
yourself at home in the Subversion development community.


> > I have a counter〓proposal for Dustin, and for Luke (if interested):
> > Would the two of you be willing to take over maintenance of
> > svnmerge.py in the svn.collab.net repository?
> > If so, I will mail you the details off〓list.
> 
> I am interested in learning any details; then I'll discuss w/ my employer. 

Okay.

> It could be a good thing; at a minimum saving me the time of breaking current
> patch into chunks (assuming I can explain and modify it to Dustin's
> satisfaction; I can still break it up if preferred).  I'm now in the process
> of working through his suggestions.

It'd still be better to commit some of your unrelated test suite
changes in a separate change set (this ought to be pretty easy,
requiring only a little extra effort on your end).  This keeps the
change history cleaner, and the changes themselves smaller, resulting
in an overall win in comprehensibility over time.

> One thing Dustin asked for was a textual description of the changes for the
> list.  I'll provide that now while I work on the rest.  However, if the code
> itself is unclear I think I should make it clearer.  I'm also happy to
> elaborate on this in any way that you think would be helpful:
> 
> The heart of the changes (and the easiest place to start reading them, IMO)
> are in action_merge(), where just before the script calls this:
>     svn_command("merge --force -r
> ..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 saves the diffs to
> temporary patch files, accumulates the comments, and returns  the information
> back to action_merge().  Subsequently, the call in action_merge() to 
>     svn_command("merge --force -r
> ..runs, and then for each file where edits were lost by the merge, it applies
> the proper patch, and appends the otherwise "lost" comments to the file
> svnmerge-commit-message.txt.
> 
> It's not necessarily pretty but seems to reduce the risk for our most common
> scenarios.  There are some scenarios that I know it doesn't support, best
> practices, tips from our internal wiki that I can share later if there's
> interest.

I understand.  Have you read
<http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts.txt> ?

While I do see a compelling need for this behavioral change, this does
strike me as a lot of complexity to add to svnmerge.py.  Perhaps after
the change sets in your patch have been teased apart, it will seem
more manageable.

> FYI also, I had to make a number of changes to get the tests run on windows,
> changing a number of things like a couple of regular expressions and the way
> the environment variables are passed to subprocesses, line terminator issues,
> etc.  Now windows gets only the same test 3 failures as linux.

These Windows change sound nice, and would also be best as in a
separate change set.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/svnmerge/attachments/20070621/05b107cf/attachment.pgp