subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Aron Bloom <sc...@towel42.com>
Subject RE: svn vs. git
Date Thu, 20 Jul 2017 22:01:10 GMT


From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Thursday, July 20, 2017 14:39
To: Subversion <users@subversion.apache.org>
Subject: Re: svn vs. git

On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jcorvel@gmail.com<mailto:jcorvel@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.

Having been coding using version code for way too long, I started with rcs, moved to CVS and
am now firmly in the svn camp.

I was forced by a third party company to work with them on a github based project.  Boy was
it painful…  But I must say, one thing I did LIKE  was the “offline” mode, of commit
vs push.

To me, it would be interesting and a very nice enhancement to enable this into subversion.
 Though I haven’t fully thought out the full flow, it would also HAVE to be optional.

But, I would very much like to be able to “check in to my personal area” while on a plane.
 Do a diff/log against that area, and then when I feel the code is ready to check into the
branch where I check out  against, I could “push” all the changes to the server.

Now, to do the same thing, I have to create either a branch of a branch (or a throw away branch
from trunk) on the server.  And check in there, until ready to merge onto top of trunk or
the brank.

The problem, is you have to be online to do this.

Soctt
Mime
View raw message