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?
Received on 2013-08-28 05:48:23 CEST