Merge tracking implementation issue.

Merge tracking implementation by means of mergeinfo property is bad.

After one of the files is individually merged, it gets mergeinfo property.

All subsequent merges, even to the head of the branch causes this file's mergeinfo
update, tags file as modified ( in a sense that it has to be commited) and then
include it's name in commit information.

After a short period of time, it's impossible
to make a merge without commiting a whole lot of irrelevant files. It is not possible
to tell from log then, which files were actually modified. This is extremely annoying.

One may argue, that merging individual file is a bad habit. But in that case why there is support
for such functionality? Or why just don't stop encourage this bad practice and outlaw mergeinfo on files?

I personally liked functionality of svnmerge utility. It has some shortcomings, too, like
making conflicts in svnmereg:integrated, but it did its job - provided merge
tracking in a controlled manner.

I understand that this new functionality is supposed to supersede svnmerge. But the way it is
implemented does at least as much harm as good. We at our company end up routinly running scripts
that deletes mergeinfo from files, otherwise it's not possible to work.

I think that the best way to fix this problem without major changes is to make mergeinfo property hidden.
Commands like status, diff, and, most important, log shouldn't show files whose only change is in mergeinfo property unless specifically told to do so by a command line switch.

-- 
Best Regards , Konstantin Kivi
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1594371
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].