[merge tracking] Granularity of merge history

On Mon, 26 Feb 2007, Justin Johnson wrote:
...
> >> Specifically I am wondering if it will track merges on a file by file
> >> basis, or will it be something like svnmerge.py's top level property
> >> that tracks previous merges of the entire branch? If it is on a file
> >> by file basis then users could merge their changes to a handful of
> >> files, and someone in a merge manager role could still perform the
> >> merge for the entire branch, which would then skip merges previously
> >> done on those handful of files.
...
> >http://subversion.tigris.org/merge-tracking/index.html
...
> >It is like svnmerge.py, although my understanding is that it should also
> >handle the case you cite.
>
> Will it handle the case when a user merges a changeset from one branch
> to another, but only accepts some of the changes in the changeset?
> For example, if a changeset modified two files and the user merged
> (cherry picked) the changes made to one of the files from branch A to
> branch B, will that merge be tracked?
>
> If that will be tracked, is the property stored on the individual file?
>
> My use of svnmerge.py is minimal at this point, but in my testing I
> did a merge and then reverted some of the changes that resulted from
> the merge before committing. But since the merge tracking was in a
> property on the top level directory (i.e. the branch) the state of the
> merge and the tracking information were inconsistent. The tracking
> information said I had merged a particular changeset in full, but my
> revert resulted in only partially merging the changeset.
>
> I was hoping that the merge tracking would be stored on the file so
> that if I revert the changes on the file, or if I only merge part of a
> changeset to begin with, merge tracking remains consistent with
> reality.

The merge history for Subversion's Merge Tracking is inherited, and
tracked at the appropriate level of granularity. Sometimes this is at
the file-level.

In other words, it does the Right thing.