[Svnmerge] Bi-directional merging becoming more painful

[Blair Zajac]

Archie Cobbs wrote:
> Blair Zajac wrote:
> 
>> So I think as a community, we should decide on the dot files or the 
>> slow approach.  Maybe we implement both?  Having the dot files there 
>> won't prevent the slower solution from working.
> 
> 
> How about this..
> 
> The same code would be used to (a) create the dot file initially
> (to initialize a branch for the "fast" approach) and (b) regenerate
> the dotfile information (when doing the "slow" approach).
> 
> So supporting both use cases shouldn't be very much extra work.
> 
> So then svnmerge could have a new command to intialize the dot file.
> This would be done once on an existing svnmerge branch; for newly
> initialize svnmerge branches, it would be created automatically
> when doing "svnmerge init".
> 
> Thereafter, "svnmerge merge" would use the dot file if it exists
> ("fast"), or not use it if it doesn't exist ("slow").

Since checking svnmerge-integrated properties is the main issue in getting a 
tree, I ran a test on how long it takes to run 'svn propget' over a large number 
of revisions to a repository on our LAN.  The script I used is below, which 
shells out the same way that our Python script does.

Checking 17714 revisions took 3h 4m 54s, averaging 0.6262 lookups per second.

I don't think this is too slow and I would like the svnmerge to build a complete 
tree by default.

Regards,
Blair



#!/usr/bin/ruby

rev_start = 76127
rev_end = 93840
url = 'http://somerepos.com/'

time_start = Time.now

(rev_start..rev_end).each do |r|
   puts r
   system("/usr/bin/svn pg svnmerge-integrated -r #{r} #{url} >/dev/null")
end

time_end = Time.now

time_elapsed = time_end - time_start
puts "Elasped time #{time_elapsed} seconds"