RE: Presentation for Berlin 10-13 June - "The future of merging with Subversion"

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_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
Received on 2010-05-28 09:59:41 CEST