On Tue, Aug 27, 2019 at 09:41:37AM -0700, bryce.schober_at_gmail.com wrote:
> 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.
Many such ideas have been proposed and discussed over the past years.
What has always been getting in the way of making such changes now are SVN"s
strong backwards-compatibility promises. These have been of great advantage
to both the project and its users, but the flip side is that making invasive
changes is getting increasingly hard as more features get added over time.
If the people involved in designing merge-tracking for SVN 1.5 had known
what we know today, things would likely look very different. Mergeinfo
would ideally be stored as pure meta-data and remain mostly invisible to
the user. Tree conflict detection should have been built in from day one.
But all that is water under the bridge at this point.
Furthermore, today, the project lacks sufficient developer resources to
make very large changes in the first place. We will keep maintaining the
code for years to come, but large new features are unlikely to be developed
unless the development community grows again.
Cheers,
Stefan
Received on 2019-08-27 19:13:14 CEST