Re: Moved file resolution fails

Tue, 30 Jan 2024, /Sands, Daniel N./:

> So far I have not found a use case where moved file resolution in 1.8+ 
> works as advertised on 1.7 servers.  But more specifically, I have the 
> following case:
> 
> The trunk has a directory,
> /foo/bar
> 
> In my local branch, I have relocated bar to
> /baz/bar
> 
> Meanwhile, in the trunk, file /foo/bar/example.c got updated.  My local 
> branch has been checked out from the 1.7 server so it no longer knows 
> specifically about file moves.  When I merge the latest changes from the 
> trunk, it creates a tree conflict on /foo/bar. It has completely lost 
> the notion that there is a file within /foo/bar that was edited.

As far as I'm aware this is all client-side behavior – nothing to do 
with the server.  Resource move/rename has always been recorded as a 
_Delete_ of the original path and a _Copy_ (Add) from the previous path 
revision.  It could be I'm missing something here, also.

> The 
> conflict data only knows that /foo/bar doesn't exist anymore.  My only 
> option for resolution is to accept working – the search for where 
> /foo/bar went also fails. And now the incoming edit to example.c is 
> completely lost, and I wouldn't even know it existed until I did an svn 
> diff on each revision that got merged in.

If I remember correctly, this had only worked the way you expect – 
automatic content merge into the moved file, pre-Subversion 1.6 when 
tree conflicts have been introduced.  I have never been a fan of this 
change and the complication to the svn merge it adds.

The way you generally resolve tree conflicts is with an extra merge (but 
could also be a delete) command per file/tree conflict:

     svg merge ^/foo/bar baz/bar

Then you mark the conflicting files (command per path) as resolved:

     svn resolve baz/bar --accept working

and finally commit, if you're satisfied with the state.

-- 
Stanimir