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

Re: Filtering changes to svn:mergeinfo properties

From: Martin Bischoff <tinu44_at_gmail.com>
Date: Tue, 21 Apr 2009 23:47:22 +0200

On Tue, Apr 21, 2009 at 13:15, Dariusz Olszewski <dol_at_globema.pl> wrote:
> Hi,
>
> At my company we use subversion for about 8 month now. Our repository grows quite quickly - we have made about 15.000 commits so far. Since we share quite a lot of code between our projects, we use merging *A LOT*. Currently we are in the situation where merges to/from our library of shared code result in changing of around 300 directories with explicit merge info.
>
> It is now extremely difficult to see actual code changes among all those svn:mergeinfo property changes.
>
> At this moment this our *top* usability problem with subversion.
>

For me this is also the biggest problem that we have with subversion.
When we do a merge, then often more than 80% of the modified files
have no changes in their content, but only in their mergeinfo
properties.
I'm not sure if this behaviour is viewed as a bug (by the subversion
developers) or if it's "by design".

This topic appears regularly in the mailing lists, but it seems it's
difficult to get answers to questions such as:

- is it required to commit the mergeinfo changes after a merge
- will this be better with subversion 1.6.x (I'm still on 1.5.6)
- can/should we remove any mergeinfo on all folders/files in trunk
once all feature branches were reintegrated
- how can excessive mergeinfo be prevented (what exactly causes it)

Maybe these things are even documented somewhere and I haven't found it yet.

Regards,
Martin

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1849203

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-21 23:48:17 CEST

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

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