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
