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

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

From: Danil Shopyrin <danil_at_visualsvn.com>
Date: Fri, 12 Sep 2008 21:33:48 +0400


I have a demo patch that tries to solve problem initially discussed at
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.

This patch (or its improved version) can:
- avoid most of the pain with unrelated mergeinfo changes. This problem
  was discussed at http://svn.haxx.se/dev/archive-2008-09/0008.shtml
  and other threads.
- solve the 'commit-is-prohibited-after-merge' bug described at
- significantly improve merge performance

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?


With best regards,
Danil Shopyrin
VisualSVN Team

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 19:34:03 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.