RE: Presentation for Berlin 10-13 June - "The future of merging with Subversion"
From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 28 May 2010 09:58:57 +0200
> -----Original Message-----
I'm thinking that a lot of users don't see the difference between the true rename support and 'true copies' when merging. (I borrowed that name from the IRC chat on this same topic).
When you merge a copy operation, you see an incoming copy from the merge source, while you sometimes would like to see a copy from the same file in the merge target.
The merge_tests.py refactoring would be a (not so good) example of this operation. If you want to merge that to 1.6.x you would see changes in the merge_tests.py on the branch (and a lot of conflicts), and the addition of the two new files exactly as they appear on trunk today.
What I would like to see (for this feature) is that these two new files are based on the merge_tests.py on the branch. (I don't know what I would expect the new text to be... probably the same as today; or just a huge conflict to solve by the merge tool)
For this specific case you would see a lot of conflicts, but when you are duplicating files to apply changes later you get a completely different line of history for these files then what you expected.
(And I don't think you need any backend changes to support this; but you probably do need some ra layer changes to support this in merges)
I wouldn't be surprised if trumerge has a better name for this then 'true copies'
This is an archived mail posted to the Subversion Dev mailing list.