> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: vrijdag 28 mei 2010 5:53
> To: Julian Foad
> Cc: Subversion Development
> Subject: Re: Presentation for Berlin 10-13 June - "The future of merging with
> Subversion"
>
> C. Michael Pilato wrote:
> > Julian Foad wrote:
> >> Did you mean to imply that use of the phrase "true renames" should be
> >> limited to this storage layer? That's not the impression I have.
> >
> > I'm not trying to say that the term has no meaning outside of discussions
> > related to the storage layer. Just that:
> >
> > - any conversation about supporting the "true rename" idea in Subversion
> > thoroughly hinges on fundamentally different treatment of renamed
> > objects in that filesystem layer, and
> >
> > - the only place we've ever attempted to implement true renames is in
> > that filesystem layer.
> >
> > - it remains to be demonstrated that "true renames" are required for
> > Subversion to work as users expect. I am fully convinced that if
> > Subversion would properly handle what it offers today (deletes, copies,
> > and their conjugation under the rename umbrella) we wouldn't be
> > having any conversations about "true renames" at all. Nobody really
> > cares how we model our renames as long as common stuff like updates
> > and merges just work.
>
> And:
>
> - before you start telling business users that Subversion needs to
> support true renames before it can meet their needs, prove it.
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'
Bert
