RE: Keyword expansion from merged changes
From: Andrew Reedick <Andrew.Reedick_at_cbeyond.net>
Date: Mon, 6 Jan 2014 09:53:29 -0500
> -----Original Message-----
IMHO, you should change your process to not rely on keywords, for the simple reason that merge edge-cases require human intervention and/or interpretation (e.g. extra changes made in the merge revision, non-trivial conflict resolution, partial merges, reverse merges, cherry picked merges, record only merges, etc.) The svn tools (e.g. 'svn diff' or 'svn mergeinfo --show-revs eligible') simply help to notify you that there may be a problem that needs to be investigated. A difference between exported code bases could be acceptable, but only a human can make that determination. "Missing" merges may be okay if the skipped revisions represent an unwanted or incomplete feature, (i.e. you don't want to merge incomplete work to trunk.)
From a previous post:
There are two types of bicycle riders: those who have fallen and those who have yet to fall. Right now you have a very easy to merge code base since you can "safely" make the assumption that exported merges should be identical. But trust me, you will eventually hit a merge edge case which completely negate your ability to maintain that assumption.
Your process, workflow, and issue/defect/bug/ticket tracking system should be instrumental in ensuring that work is being tracked (in addition to 'svn mergeinfo' and 'svn diff'.) A "merge aware" keyword just isn't enough, because even if a "merge aware" keyword were implemented, it would become useless once you hit a merge edge case.
This is an archived mail posted to the Subversion Users mailing list.