If I happen to have duplicated a previous proposal, I would appreciate a redirect; but my search-fu hasn't been adequate to find any.
The reasons for not supporting the equivalent of the CVS $Log$ keyword in Subversion are well-documented, in the FAQ: I would also note that such global comments are often inadequate, or even misleading. However, there are legitimate reasons for developers to include manual change logs in individual files, and these still make merges painful. To resolve such "log conflicts" manually, I will typically concatenate distinct insertions in commit order, remove the "source" copies of any common insertions, and honor common deletions. Since this is a more-or-less mechanical process, it seems, to me, like good a candidate for automation, provided means for users to specify a boundary of application, such as paired, leading and trailing keywords (e.g. '$LogBelow$' and '$LogAbove$'). Note these keywords would be positional merge hints only: there would be no automated insertions, and any other conflicts remaining--such as distinct deletions--would still require user intervention. The intent is only to spare the user widespread, trivial conflicts, in a use case often driven by procedural requirements. Also, it would be appropriate still to refuse commits, until after the user has inspected the file and marked it resolved, even if there were no other conflicts remaining; but it would be helpful to show a weaker marker in 'svn status', for convenience. Of course, these would have to appear in 'svn:keywords': if both were enabled, they would have to appear in pairs; and if only one were, its effect could be anchored (applied only to contiguous changes appearing immediately after the leading keyword, or before the trailing, with no unchanged content interposed). -- Eric Roesinger : Senior Firmware Engineer eroesin...@troygroup.com : TROY Group, Inc. Tel#: 304 232-0899 x114 : 3 Bryan Drive FAX#: 304 232-1028 : Wheeling, WV 26003 USA
