On Thu, 21 Jun 2007, [EMAIL PROTECTED] wrote: > >>> On Thu, Jun 21, 2007, Daniel Rall <[EMAIL PROTECTED]> 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.
pgpSm7dUTX9vh.pgp
Description: PGP signature
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
