[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Useless explicit mergeinfo records

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 02 Sep 2008 16:57:26 -0400

"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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.