On Fri, Apr 9, 2010 at 08:27, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Paul Holden [mailto:paul.hol...@gmail.com] >... >> 2) subversion appears to generate a temporary file in .svn\prop-base\ for >> every file that's being updated. It's generating filenames sequentially, >> which means that when 5,800 files are being updated it ends up doing this: >> >> >> file_open tempfile.tmp? Already exists! >> >> file_open tempfile.2.tmp? Already exists! >> >> file_open tempfile.3.tmp? Already exists! >> >> ...some time later >> >> file_open tempfile.5800.tmp? Yes! > > Wow.
Yeah, Wow. And I'll raise you an Ugh. > Are you sure that this is in prop-base, not .svn/tmp? Whatever. Does it matter? :-P I think we should backport the changes we made in svn_io_open_unique_file3. > For 1.7 we made the tempfilename generator better in guessing new names, but > for property handling we won't be using files in 1.7. (Looking at these > numbers and those that follow later in your mail, we might have to look in > porting some of this back to 1.6). Yah. >... >> Is there any inherent reason these files need to be generated > sequentially? >> From reading the comments in 'svn_io_open_uniquely_named' it sounds like >> these files are named sequentially for the benefit of people looking at >> conflicts in their working directory. As these files are being generated >> within the 'magic' .svn folder, is there any reason to number them >> sequentially? Just calling rand() until there were no collisions would >> probably give a huge increase in performance. > > In 1.7 we have a new api that uses a smarter algorithm, but we can't add > public apis to 1.6 now. Not a new API. Just a revamp of svn_io_open_unique_file3. Compare the 1.6.x version against trunk. Paul: if you're adventurous, and build your own svn, you could try lifting the contents of trunk's svn_io_open_unique_file3, and dropping that into your 1.6.x. >... Cheers, -g
