On Thu, 06 Apr 2006, Daniel Rall wrote: > On Wed, 05 Apr 2006, Giovanni Bajo wrote: ... > > I'm confused as to why "svnmerge integrated" should ever run "svn log" (or > > even > > run any remote operation at all). > > I don't think the code that's there ATM is quite right, because it's > looking for the oldest branch revision instead of the oldest source > (head) revision.
Back from a brief vacation, I had time to glance over this today with David James. This was indeed a bug in 'integrated', fixed in r19337 of Subversion's trunk. > However, the 'svn log' may still be needed for > correctness and/or consistency with 'svnmerge.py avail', because the > "svnmerge-integrated" property records more revisions in its revision > ranges than have actually been merged into a branch... > > For example, consider a vanilla test case > (post-TestCase_TestRepo.setUp()) in svnmerge_test.py: > > A propget of "svnmerge-integrated" on "test-branch/" has a value of > "trunk:/1-6" before any changes have merged from trunk into the branch > (but post-'init'). Considering that trunk wasn't even born until r3, > why should the 'integrated' command claim that revisions 1-6 had been > merged when in fact only 3-6 -- the birth of trunk through the > revision the branch was copied from trunk -- have actually been > (implicitly) "merged" into the branch? > > > Perhaps the storage format of the revision ranged used in the > "svnmerge-integrated" property is a simplifying assumption used by the > implementation 'svnmerge.py avail' to calculate the set of revisions > available (in this case, 9-10)? During some initial testing of the > patch for the in-the-works 'rollback' command, David James and I found > that we did want to ignore this set of "too old" changes during the > rollback process. However, perhaps this is not appropriate behavior > for 'integrated'...thoughts? I've seen no comments on this, so I left the implementation as-is, *not* claiming that revisions which predate the source URL have been integrated into the destination WC. While passing the output of 'integrated' to 'svnmerge.py rollback' or 'svn' probably would work fine, I dislike the tool claiming that it's merged revisions which it couldn't possibly have merged. The cost of one 'svn log' operation seems like a reasonable trade-off here. > Dan wrote: > > > Blair wrote: ... > > 2) It took a lot of CPU time and clock time (over 3 minutes). After it > > runs the > > > > svn log -r 1:HEAD --limit=1 -q . > > > > there's no visible indication of what the script is doing. I assumed that > > it was stuck in the response from the svn log, but it turns out that that > > returns in a couple of second, so that's not the cause. > > > > It would be good to have an additional message stating what its doing then. > > I suspect that the extra time may be due to subtracting the > revisions which predate the branch (svnmerge.py at 19195, line > 1011), ... This turned out to be the cause of the slowness, which was caused by passing a list to RevisionSet.__sub__(). Changing this to pass a revision set -- also in r19337 -- improved performance by operating on a dict instead of a list. -- Daniel Rall
pgpT6FbNhuBty.pgp
Description: PGP signature
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
