> -----Original Message----- > From: James Hanley [mailto:jhan...@dgtlrift.com] > Sent: Saturday, January 04, 2014 2:47 AM > To: Ben Reser > Cc: users@subversion.apache.org > Subject: Re: Keyword expansion from merged changes > > > > So in my opinion I don't think this is a good suggested feature. > > Fair enough, and one of the workarounds you previously mentioned may be > useful, but in my opinion there is still gap between keywords and merge > history even if this specific feature proposal is not a desired > solution to close that gap. > > Where do we go from here?
Nowhere. <soapbox> 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: "our need would be for during the release process for validating all changes are completely synchronized and that there are no missing changes between branches, but aside from our need, it just doesn't seem right that there would show differences between the exported branches" 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. </soapbox>
