Re: Rename tracking [was: Presentation for Berlin 10-13 June - "The future of merging with Subversion"]

[Johan Corveleyn <jc...@gmail.com>]

On Fri, May 28, 2010 at 2:11 PM, Stefan Sperling <st...@elego.de> wrote:
> On Fri, May 28, 2010 at 02:07:15PM +0200, Stefan Sperling wrote:
>> Please consider taking a very good look at how Mercurial handles copies
>> when merging.
>
> And BTW, a rename in Mercurial is also a copy+delete.
> That's why I think what they are doing is quite relevant to us.

Please don't reduce the issue of "rename tracking" (or whatever you
want to call it) to merging. It's just as relevant for updating (cf.
tree conflicts of "local edit, incoming delete" and "local delete,
incoming edit", etc., which you can just as easily get with a normal
update). When there is proper rename tracking, I fully expect these
kinds of tree conflicts to be resolvable automatically (most of the
time). Whether it's a merge or a regular update.

Unless you consider an update a special kind of merge. However, I
don't think that's the case in the mind of users (at least in my head,
as a user, the two are quite different, I use them in totally
different contexts). That's why I think "Branch-relative renames" is
not such a good term. It couples the rename issue to
branching/merging... It's more than that.

Cheers,
-- 
Johan

Re: Rename tracking [was: Presentation for Berlin 10-13 June - "The future of merging with Subversion"]

[Mark Mielke <ma...@mark.mielke.cc>]

On 05/28/2010 09:33 AM, Johan Corveleyn wrote:
> Please don't reduce the issue of "rename tracking" (or whatever you
> want to call it) to merging. It's just as relevant for updating (cf.
> tree conflicts of "local edit, incoming delete" and "local delete,
> incoming edit", etc., which you can just as easily get with a normal
> update). When there is proper rename tracking, I fully expect these
> kinds of tree conflicts to be resolvable automatically (most of the
> time). Whether it's a merge or a regular update.
>
> Unless you consider an update a special kind of merge. However, I
> don't think that's the case in the mind of users (at least in my head,
> as a user, the two are quite different, I use them in totally
> different contexts). That's why I think "Branch-relative renames" is
> not such a good term. It couples the rename issue to
> branching/merging... It's more than that.
>    

It may depend on the user. For myself, any 3-way merge (or better) that 
takes changes on one side and applies them to the other, is a merge. The 
"svn update" operation is by definition a merge, as it takes the changes 
made in the repository and applies it against the changes made in the 
workspace.

I have noticed that Subversion merge capabilities seem slightly 
different between "merge to workspace" and "merge to branch". Note, 
though, that this difference perplexed and confused me. Why should "svn 
update" be smarter or not as smart as "svn merge" when presented with 
the same amount of merge context, the same "base version", the same 
resulting context for a "source version", and the same resulting context 
for a "target version". I recall playing with what most people here are 
calling "tree conflicts", and I stumbled upon a situation that work fine 
with "svn update", but then failed with "svn merge". Augh! :-)

In any case - you can define it however you wish - but as a user, I 
expect "rename commit plus file content commit" to be equally mergeable 
to both another branch and the local workspace. One day. :-)

Thanks,
mark

-- 
Mark Mielke<ma...@mielke.cc>

Re: Rename tracking [was: Presentation for Berlin 10-13 June - "The future of merging with Subversion"]

[Julian Foad <ju...@wandisco.com>]

Johan Corveleyn wrote:
> On Fri, May 28, 2010 at 2:11 PM, Stefan Sperling <st...@elego.de> wrote:
> > On Fri, May 28, 2010 at 02:07:15PM +0200, Stefan Sperling wrote:
> >> Please consider taking a very good look at how Mercurial handles copies
> >> when merging.
> >
> > And BTW, a rename in Mercurial is also a copy+delete.
> > That's why I think what they are doing is quite relevant to us.
> 
> Please don't reduce the issue of "rename tracking" (or whatever you
> want to call it) to merging. It's just as relevant for updating (cf.
> tree conflicts of "local edit, incoming delete" and "local delete,
> incoming edit", etc., which you can just as easily get with a normal
> update). When there is proper rename tracking, I fully expect these
> kinds of tree conflicts to be resolvable automatically (most of the
> time). Whether it's a merge or a regular update.
> 
> Unless you consider an update a special kind of merge. However, I
> don't think that's the case in the mind of users (at least in my head,
> as a user, the two are quite different, I use them in totally
> different contexts). That's why I think "Branch-relative renames" is
> not such a good term. It couples the rename issue to
> branching/merging... It's more than that.

Yup, I am certainly not forgetting updates.  Thanks for pointing out
that terminology like "branch-relative" may be misleading.

- Julian