We did a similar comparison as well, and again stuck with SVN. However,
this was predominantly due to the challenge of getting devs to relearn a
whole new process (we had enough trouble migrating from lock-modify-unlock
to a checkout/modify/commit workflow).
We did like the off-line process, and the ability to stash/unstash changes,
and the speed performance was immense.
The biggest advantage that we saw git giving us is integration with third
party apps out of the box. The number of vendors who have added git
integration into their apps far outpace the SVN integration, and it makes
it hard to stick with SVN when we can't take full advantage of these
systems. Code review is the main one, but this is driven by github.com more
than git itself, I guess.
I'm not sure what changes something like SVN 2.0 would bring, given that
the entirety of git's lifetime is wholly contained with SVN 1.x's, but it
will be interesting. I'm sure the devs are looking/investigating that.
On Fri., 21 Jul. 2017, 08:01 Scott Aron Bloom, <scott_at_towel42.com> wrote:
>
>
>
>
> *From:* Nathan Hartman [mailto:hartman.nathan_at_gmail.com]
> *Sent:* Thursday, July 20, 2017 14:39
> *To:* Subversion <users_at_subversion.apache.org>
> *Subject:* Re: svn vs. git
>
>
>
> 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.
>
>
>
> 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
>
Received on 2017-07-21 01:41:16 CEST