On Wed, 07 Mar 2007, Justin Johnson wrote:
> I brought this up in a different thread but wasn't getting a response,
> and it seemed more appropriate to start a new thread specific to my
> question.
>
> First, my understanding is that cherry picking refers to merging a
> single complete change set (i.e. revision) instead of the entire list
> of revisions that need to be merged. Correct me if I am wrong.
The current plan is support merging of only portions of a change set.
I've updated the Cherry Picking use case to better reflect this:
http://subversion.tigris.org/merge-tracking/requirements.html#cherry-picking
> Here's my question.
>
> Will the new merge tracking handle the case when a user merges a
> change set (cherry picking) from one branch to another, but only
> accepts some of the changes in the change set? For example, if a
> change set modified two files and the user only merged the changes
> made to one of the files from branch A to branch B, will that merge be
> tracked? It seems to me like this isn't possible today with
> svnmerge.py, since the merged revision is stored at the root directory
> and implies the entire revision (i.e. it has no way to specify only
> certain files in that revision). If the property that stores what was
> merged was stored on the individual file/directory, someone could
> merge parts of a change set at one time if needed, and the rest of it
> at another time. Or the user could merge the entire change set, and
> before committing decide to revert the changes made to one of the
> files but still merge the rest of the changes. The revert on the file
> would revert both the merged changes and the property on that file
> specifying that the merge took place.
The plan is support all of this. Implementation is underway on the
merge-tracking branch.
- application/pgp-signature attachment: stored
Received on Thu Mar 8 01:25:06 2007