On Thu, Oct 28, 2021 at 09:01:02AM -0500, Luke Mauldin wrote: > You mention renames as an example of a problem that are unlikely to ever be > resolved. Can you please elaborate on the issue? My understanding is that > especially the newer versions of SVN potentially do a better job of tracking > renames than Git because SVN actually tracks more file level information > whereas Git only tracks the contents of files.
I guess what Mark was referring to is a solution that would involve server-side changes. Many potential solutions were discussed over time, and some of them were even partially implemented but never went beyond experimental status. Several proposals included changes to the repository storage format as well as network procotol changes. Our current solution for resolving tree conflicts is client-side only, and as such it may not fit everyone's definition of "rename tracking". Essentially, the client runs the equivalent of 'svn log -v' and traces copyfrom information and deletions of relevant paths to figure out whether a rename might have occurred. In other words, it does exactly what a competent human would do to understand a rename conflict situation. The client has to fall back to human guidance in case of ambiguity, where multiple copies map to the same deleted path. In a perfect world the client should not have to fall back on human guidance because the user did already inform Subversion about the rename when they ran 'svn move'. However, a move operation is translated to copy+delete when a commit is made, so any move information the client had recorded is lost. On the upside, our current approach works against any server, which is important since it is generally easier to install up-to-date clients than upgrading existing server deployments. And the conflict resolution framework we have in the client has been designed with extensibility in mind. It is possible to add support for additional conflict cases by implementing a couple of funtions of C code. The current coverage is not complete, most importantly it doesn't handle cases where files have become directories or vice versa. But the only reason it does not handle such cases is lack of time and motivation to work on the missing bits. There is no technical reason it couldn't be done. What we have now seems to be good enough to cover what most people need. We do not hear complaints about this topic anymore so either people who used to complain have abandoned SVN or the solution we have is good enough. We cannot really tell the difference :)
