fre 2 feb. 2024 kl. 06:52 skrev Sands, Daniel N. via users < users@subversion.apache.org>:
> > 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. > > As of 1.8, it now knows if an add or delete was due to a move. For > example, on my RHEL8 system that has 1.10, a move will look like this in > status: > > D foo/bar > > moved to baz/bar > A baz/bar > > moved from foo/bar > > If I use this tree to update from even the 1.7 server, conflict resolution > can find the change in the trunk to foo/bar/example.c and rewrite it to > baz/bar/example.c. The conflict resolution gives me the option to > (u)pdate the destination of the change. > > However, if I check out my local branch from 1.7, the above 'moved' > information is lost. Which version are you using on the client side? Can you show the output of svn —version? Kind regards Daniel Sahlberg And in that case, conflict resolution fails. There is a > published paper that 1.8+ clients implement in resolving the new path in > the absence of the 'moved' information. It involves a heuristic where > 1) the delete and the add must happen in the same checkin > 2) the adds will be searched for some kind of common ancestry that can be > used to match the add to the delete > > But whatever was implemented, the tree conflict search does not seem to > find its common ancestry. In addition, the example.c file modification > record is lost, so after resolving the tree conflict there is still an > incomplete merge even though it has the merge info recorded. > >
