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

Re: Proposal: don't modify any unrelated mergeinfos during 'svn merge'

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 12 Sep 2008 14:12:09 -0400

2008/9/12 Danil Shopyrin <danil_at_visualsvn.com>:

> The logic and implementation of the patch is as simple as possible:
> - we record (modify/elide) mergeinfo only for paths, that are
> ancestors of paths that are somehow touched by merge. Looks like it's
> absolutely unnecessary to modify mergeinfo for any other paths since
> these paths aren't anyhow touched by performed merge operation;
> - current implementation is quite naive. We get the list of touched
> paths from the notification_receiver_baton_t.
> It's most likely incorrect but we can find the better source of
> information about touched paths;
> - a lot of merge_tests.py tests are falling with the proposed demo
> patch. It's because these tests relies on the
> fact that unrelated mergeinfo will be modified/elided after merge.
> It can be easily fixed when the whole concept wioll be approved.
>
> I want to get the following feedback:
> - is the whole idea correct?
> - what is the right source to get the list of paths that are somehow
> touched by merge operation?

The current behavior is intentional, even if undesirable. AFAIK, Paul
knows what to do to change it, the issue is getting consensus that we
want to do it. There are consequences to not eliding. Not fatal by
any means but there is still an impact to not doing this.

We've discussed this before informally at CollabNet, and I think we
were all in favor of this, perhaps with a little uneasiness.

-- 
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-12 20:12:35 CEST

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