Stephen,
Thanks for the info. That's more or less the interaction I was afraid of.
You mention this problem can be avoided by changing the branch mappings
to explicitly reference the new file. Could you please give me an
example of how this is done?
Thanks,
Ollie
Stephen Vance wrote:
Ollie --
Right now, when the rename is merged, it will merge as a delete and an
add. When the edit is merged, it will merge as an edit.
The actual results depend on the order of the merges, but neither is
probably what you want. If the edit is merged first, the result will
be that the edits have been occluded by the time you finish the rename
merge. If the rename is merged first, you will either have to abandon
the edits or you will have to re-add the file using the original
branch mapping.
I would guess your intent would be to have the edits present in the
renamed file. To do this you would have to change the branch mapping
to explicitly draw this association.
I don't believe this will change with the enhanced integration
capabilities in 2002.2. It will just make it easier to migrate the
changes into the renamed file.