From: Nathan Hartman [mailto:hartman.nat...@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 <jcor...@gmail.com<mailto:jcor...@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
