On Thu, Nov 17, 2011 at 8:02 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Johan Corveleyn wrote on Thu, Nov 17, 2011 at 13:55:51 +0100: >> On Thu, Nov 17, 2011 at 1:02 PM, Philip Martin >> <philip.mar...@wandisco.com> wrote: >> > Attila Nagy <b...@fsn.hu> writes: >> > >> >> On 11/16/11 18:40, Philip Martin wrote: >> >>> Attila Nagy<b...@fsn.hu> writes: >> >>> >> >>>> I use pysvn for this and basically the code looks like this (in python): >> >>>> def update_perms(): >> >>>> for path in propchg: >> >>>> proplist = svn.propget('file:permissions', path) >> >>>> if not os.path.islink(path) and proplist.has_key(path): >> >>>> set_perms(path, proplist[path]) >> >>>> svn.update(walkroot) >> >>>> update_perms() >> >>>> >> >>>> The svn update collects the changed entries (propchg) and update_perms >> >>>> iterates on them and gets their file:permissions property and sets it >> >>>> in the file system. >> >>>> >> >>>> And this is what takes ages (literally), compared to 1.6. >> >>>> Any ideas about what could be done in this topic? >> >>> >> >>> It might be faster to run a recursive propget, which is a single >> >>> transaction, and discard the output if it doesn't match one of the >> >>> changed paths. >> >>> >> >> I will try this. Should this be true even for 10+ million files? >> > >> > It depends on the ratio of changed files to total files. If there is >> > only one changed file then the single propget will be faster. If most >> > of the files are changed then the recursive propget will be faster. >> >> Yes, you'll need to test that a bit. >> >> I do something similar here with a script that fetches all the log >> entries for merged revisions (cherrypick merges, which I look up with >> 'svn mergeinfo --show-revs merged'): if the number of merged revisions >> is low relative to their range, I perform a series of individual 'svn >> log' requests. Otherwise, I do a single 'svn log -r<min>:<max>' >> request, parse the output and discard the entries that are not >> relevant. This made my script much faster in most cases. >> >> This has nothing to do with recursive propget (or even with 1.7, I'm >> using this in a 1.5 environment), but I'm just noting the similarity >> of the problem here. > > svn log -r N -r M -r P > > was implemented a few years ago...
Indeed. But that was 1.6+, and I still have to support some 1.5 clients with this script. So unfortunately I had to write this workaround :-). But thanks for pointing this out, even if only for completeness of the archives :-). -- Johan