Branko Čibej wrote on Sun, Aug 25, 2013 at 15:39:29 +0200: > On 25.08.2013 15:03, Daniel Shahaf wrote: > > 'svn mergeinfo' walks the tree upwards. As to listing branches by > > walking the tree downwards, if you consider 'svn pg -R svn:branch > > ^/branches', and let N = number of branches and M = number of files per > > branch, it would do O(NM) work to compute an O(N)-sized answer. > > That's assuming the server doesn't know about the property. But it has > to know in order to implement the branching restrictions I mentioned. >
You didn't specify whether those restrictions were to be implemented in the client or server. > Why don't you do a similar cost analysis on the original proposal, > taking into account the problems I pointed out? The cost of the original proposal is O(L) dirents-list retrievals where L is the number of patterns in the property (assuming that globs don't recurse, i.e., no "**"), and in particular is independent of M. And, by the way, I think you mentioned just one problem: the fact that the branch-roots structure is defined in a place other than the branch roots and as such may get out of date. Were there any others?
