On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> Not wanting to start a flame war, but for all svn users and admins out
> there that sometimes need to have this conversation ... I found this to be
> a very nice website:
>
> https://svnvsgit.com
>
> (I'm not affiliated with the website, just ran into it)
>
Thank you! Thank you! Thank you!
I did recently have this conversation and this website could have helped
significantly.
There seem to be some comparisons out there that are comparing DVCSs
against ancient versions of Subversion. Probably those comparisons are old
and therefore their argument may have been valid at the time. But if those
comparisons are more recent, then there's a problem. Either the person
making the comparison is honestly unaware of progress made in Subversion's
development over the years, or they are deliberately comparing to old
versions to make Subversion look bad.
Regardless of how or why, I think the perception out there is just plain
wrong. I think Subversion is due a lot more credit than it gets. As I
mentioned in another thread (which may have prompted this one), we recently
evaluated other systems. We did not do this out of desire to migrate away
from Subversion; rather we did it in order to understand what's happening
in our industry, and as such we wanted to answer the question: will
switching to something else give us some new advantage? We gave git and
others a fair chance, and based on various technical, usability, and
management criteria we reached the conclusion that Subversion has been and
still is the best system for us. We manage all sorts of data with it, not
just program code.
While I'm here, I'll comment on a couple of significant issues mentioned at
that site.
Item #7 mentions the issue of a single monolithic repository vs numerous
smaller repositories, and the atomic whole-project commit, consistent
branches, and large-scale rafactoring made possible by it. These are
extremely important to us. We have numerous components whose history and
state must remain matched as they evolve. With the monolithic repository,
this happens by definition. Losing that by breaking things up into multiple
repositories (to avoid cloning a gigantic monolithic repo for every working
copy) would push a maintenance burden to everyone on our team, which is
unacceptable from a management perspective.
Item #11 mentions the issue of immutable history. We know from experience
that the ability to reproduce the exact bits at a point in time is crucial
to us. With Subversion, this very significant requirement is fulfilled, and
tremendous problems we had in our pre-Subversion days have disappeared.
Losing immutable history would be a huge step backwards for us.
One myth that is not mentioned on that page is the famous, "But you can't
work offline!" Being able to work "offline" is supposed to be the biggest
selling point of a DVCS over a CVCS. Okay... I'm calling that a myth. First
of all, there is nothing inherent to Subversion that "prevents" you from
working offline. You can work, you just can't do server side operations. Is
that such a big deal? And if it is, do you mean to tell me that in this day
and age of cloud services and IoT, where every single thing you do requires
Internet access, that you're ever really "offline" for long enough that it
matters? And even if you are planning to spend a year alone on a deserted
island, nothing stops you from doing "svnadmin create" on your local
computer and making as many commits as you want. But that doesn't make
sense, because the longer you work in isolation, the less likely it is that
your work will merge cleanly when you get back. Even the smartest and
greatest DVCS in the world can't solve that problem. So this "offline"
nonsense is a myth.
Subversion is a very good system. It doesn't get the credit it deserves,
and that needs to change. Those of us who love it should give it some good
PR and try to drum up more support for it.
Received on 2017-07-20 23:38:47 CEST