FWIW, I found the explanations in these two emails from the same thread to be easier to understand as a user: https://svn.haxx.se/users/archive-2010-11/0408.shtml https://svn.haxx.se/users/archive-2010-11/0466.shtml
This sounds like yet another UX flaw caused by the constraints of subversion's characteristic "flexibility" afforded by its nearly-complete agnosticism regarding repository branching and tagging structure. As I use git more and more for all of my daily development, I continue to run into UX problems like this that are made so much less helpful and more surprising, all in the name of that ultimate "everything is just a sub-tree" flexibility. I am coming to strongly believe that this design paradigm is SVN's fatal flaw keeping it from being the best long-term centralized VCS competitor to git & other DVCSes. If subversion were to have a configurable "strict structure" mode that could both enforce and simplify its behavior in use-cases like this, it could be a big win. It could even provide simplified "tag" and "branch" aliases to "svn copy", as well as "--tag" and "--branch" options to switch, merge, etc. I suppose directions like that may have been taken before with svn wrapper systems, but those never catch on or survive unless they are upstream. <>< <>< <>< Bryce Schober On Tue, Aug 27, 2019 at 2:43 AM Johan Corveleyn <jcor...@gmail.com> wrote: > On Wed, Aug 21, 2019 at 6:55 PM Bryce Schober <bryce.scho...@gmail.com> > wrote: > > > > I just noticed that whenever we do a remote rename (from URI to URI, as > opposed to in a working copy), svn add mergeinfo that didn't exist before. > It doesn't do this for renames in a working copy. Is this by design, or by > accident? > > This is by design. See amongst others these mail threads: > > https://svn.haxx.se/users/archive-2010-11/0357.shtml > https://svn.haxx.se/users/archive-2017-11/0017.shtml > > -- > Johan >
