subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Reedick <>
Subject RE: Keyword expansion from merged changes
Date Mon, 06 Jan 2014 14:53:29 GMT

> -----Original Message-----
> From: James Hanley []
> Sent: Saturday, January 04, 2014 2:47 AM
> To: Ben Reser
> Cc:
> 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?



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.


View raw message