On Tue, Apr 21, 2009 at 13:15, Dariusz Olszewski <dol_at_globema.pl> wrote:
> 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
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.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-21 23:48:17 CEST