"Mark Phippard" <markphip_at_gmail.com> writes:
>>> Not only that, but it is horribly slow due to the wc. 20-30 minutes
>>> to do a merge operation really messed with our plans.
>>
>> I agree, and it seems like a pretty basic bug. Can you file an issue
>> about it, linking to this thread (and the one you mention above)?
>
> How could merge tracking be merge tracking if it does not do this? It
> has to scan the working copy to find out if you have any subtree
> mergeinfo.
>
> I do not think it makes sense to try and change this. If we really
> implement a new WC, this checking will become trivial as it will no
> longer be crawling the WC to find this information. That seems like a
> better solution given that the code is working as intended.
We have a real problem: metadata *about* files is being treated (for
authz purposes) as data *in* files, simply because we implemented the
mergeinfo as a property.
Thus a merge which does not actually change authz-protected files cannot
be committed, because we have no way of committing statements about
those files without committing changes to the files themselves.
The new WC will make things easier; it may open the door to totally
changing how we record mergeinfo (since, among other things, it will
make property inheritance much easier).
Unrelatedly, the slowness is still a bug, of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-02 22:57:40 CEST