On Thu, Jul 20, 2017 at 5:38 PM, Nathan Hartman
<hartman.nathan_at_gmail.com> wrote:
> 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.
Sadly, it's not a balanced analysis. It's a "why all the news about
Donald Trump is faked by the liberla media, according to Fox News"
sort of analysis.
Balancing information would include "Can Subversion or git delete
dangerously or accidentally committed bulky or security sensitive
content from the repository?" This is the longest requested feature of
Subversion, and there remains no sign of it eve rhappening. If you've
ever accidentally committed a file with customer passwords, or a bulky
.iso image or core file to a working repository and seen your central
repository grow by half a Gigabyte in a single automated commit,
you'll know *exactly* what I mean. And even if committed to a branch,
it's very difficult to clear from Subversion, and *far* simpler to
clear entirely from a git repository.
> 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.
Or they are actually looking at problems that are not the ones listed
on that webpage. The need for constant network access to the
Subversion master for making branches and changes, for example, makes
a continuous integration and continuous development entirely dependent
on that single component. Local testing branches cannot be stored
locally with change history.
> 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.
Me, too. It has its uses, and tools like TortoiseSVN make it *much*
easier to use for my Windows clients.
> 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.
And saying "git does not support this" is misleading itself. Large
*binary* repositories are problem: Subversion users can, and do, check
out single directories much more efficiently.
> 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
If you're in the git world, then lean to use "tags'. Same in Subversion.
> tremendous problems we had in our pre-Subversion days have disappeared.
> Losing immutable history would be a huge step backwards for us.
In my opinion, and it's one with decades of source control experience:
Immutable history is not, per se, a "software" problem. It's a
privilege problem. Who can and should be allowed to delete the
history? This is one of the points where Subversion, described as "CVS
done right", lost an important feature of CVS.
> 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.
You can't commit your changes. If you work the way I do, with storage
and testing of new configurations, the local commits are invaluable.
> 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
Absolutely. I've personally worked, for decades, in environments where
I *do not want* to allow the server to have 24x7 access to an
externally exposed web resource. Instead, with a DVCS, I can make the
changes locally, and *pull* them to the reference server or to an
intermediate server that is far less likely to create dangerous split
brain issues than the monolithic upstream repository configuration
typical to Subversion services.
> 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.
And that's where the "I can run a staged and reviewed pull request to
the upstream master repository" becomes priceless.
> 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.
It's extremely solid and stable and well supported for what it does as
a centralized source control system. I took it over CVS and at least 3
hand-invented CVS replacements written by CTO's I worked for in a
heartbeat, and have helped with numerous migrations. But let's be very
clear about what it *is* good at, and what it's not, because when we
talk with people we need to address their real issues. Not the ones
that this webpage claims are the issues.
Received on 2017-07-22 02:00:30 CEST