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 <jcorvel_at_gmail.com> wrote:
> On Wed, Aug 21, 2019 at 6:55 PM Bryce Schober <bryce.schober_at_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
>
Received on 2019-08-27 18:42:19 CEST