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.
> >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
The merge history for Subversion's Merge Tracking is inherited, and
tracked at the appropriate level of granularity. Sometimes this is at
In other words, it does the Right thing.
Received on Mon Feb 26 21:51:49 2007
- application/pgp-signature attachment: stored