[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 13:51:17 -0400

"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)?

Danil, a workaround for this problem...

> When user merges any change from a branch to the trunk, mergenfo for
> $/trunk/core/corefile.txt will be changed (even if corefile.txt isn't
> somehow touched by this change). And if user doesn't have write access
> to the core folder then he will not be able to commit this change.

... is to simply exclude the authz-blocked path from the commit, by
naming commit targets explicitly. That's cumbersome, but it can be
done until this situation is fixed.

By the way, I also looked in the issue tracker for an issue about this,
and didn't see any. FWIW, I specifically checked these:



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 19:51:37 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.