On 28.08.2013 05:47, Daniel Shahaf wrote:
> 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.
I thought it's obvious that the server has to implement the
restrictions, otherwise an older client can mess up your branch
metadata. The same is true of the original proposal. Without explicit
server support, it's even easier to get the branch property out of sync.
>> 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?
That is the root cause of all the others I mentioned. And by the way,
your analysis depends on the assumption that there is exactly one such
property in the repository (or project subtree if you want to call it
that), and that you never have nested branches, etc. A bit naive in my
Anyway, this thread has gone far beyond the mandate of the users@ list.
We should discuss the features on dev@ without the hand-waving.
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
Received on 2013-08-28 11:26:07 CEST