Re: svn copy, branch & mergeinfo

Andrea <mariofutire_at_googlemail.com> writes:

> What happens is that, using tortoise, when I merge from trunk to
> branch and I am asked to select which revisions to pick I see the log
> of trunk and there, I have no idea what is already part of the history
> of the branch (because it was before the branch point) or after.

That sounds like a bug in tortoise, and it would be helpful to report
it to them.

> While with my change, all revisions 1-1234 are greyed out and cannot
> be selected.

Sure, but that's tortoise rejecting them because they are recorded as
merged, even though they aren't, not tortoise rejecting for the right
reason. They shouldn't even show up greyed out because merging them
makes no sense (other than to revert/unrevert a changeset, but that's
independent of branches).

> "--stop-on-copy" works when looking at the history of a branch, but it
> does not help at all when I am asked to select a revision from trunk
> to the branch.
>
> Maybe some warning message saying (e.g. rev xxxx is already part of
> the target history) could be as helpful.

Definitely, but I think the biggest leverage fix is not presenting
natural history as mergeable.

I am pretty sure command-line svn gets this right when you look at
eligible revs.

Quite separately, you may want to consider your workflow and if
handpicking revisions to merge is really what you want. We use 'feature
branches', where we routinely merge all unmerged revisions from trunk to
each branch, and then do a a reintegrate merge when the feature branch
is tested. We also have "stable branches" that get the
hand-picked-revisions treatment you are describing.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2368188

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].