On Tue, Sep 2, 2008 at 10:51 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "Peter Wemm" <peter_at_wemm.org> writes:
>> On Fri, Aug 29, 2008 at 2:22 AM, Vincent Lefevre <vincent+svn_at_vinc17.org> wrote:
>>> On 2008-08-27 17:00:26 +0400, Danil Shopyrin wrote:
>>>> 1) Merge touches all files with explicit mergeinfo even if content of
>>>> these files isn't touched by merged revisions. This can result in
>>>> inability to commit changes after merge.
>>>
>>> Yes, I noted this problem in the users ML:
>>>
>>> "svn merge" scans the whole wc and deletes svn:mergeinfo properties
>>>
>>> This is really annoying. Even if there are technical reasons, this
>>> should be regarded as a bug IMHO.
>>
>> 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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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:43:34 CEST