At Thu, 18 Apr 2019 09:23:31 +0100, Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote: Subject: Re: Alternative DVCS to git: hg? > > On Thu, Apr 18, 2019 at 6:17 AM Greg A. Woods <woods%planix.com@localhost> wrote: > > SVN is a big steaming pile, though with "git svn" it can be held at > > arm's length (though not quite far enough that the stench doesn't still > > wear on one). > > Could you quantify the above statement? You seem to be saying > Subversion is a pile of crap because it's not Git and doesn't have > Github. OK Subversion is not distributed so some work-flows that > people use with Git are not going to work, but aside from that, what > are the actual problems that you have with Subversion? Assuming that > you always have connectivity to the central server, how is Subversion > stopping you from being productive with branches, merges and commits? Well, let's start with how huge the pile is vs. what you get for it, especially in a normal unix-y environment as would be used by NetBSD. A lot of the CVS problems supposedly solved SVN were not really CVS problems per se, but rather problems faced by Windows developers (or at least Windows-focused developers) not used to working with text files and not used to working in or having access to proper networking and distributed systems and servers (as we in the unix-y world knew them at the time of SVN's development). So, the result was they conflated a large number of problems into things they thought the version control tools should solve instead of problems inherent in their environment. This brought in piles of extra crap and hooked it into the end product in ways that it could not be ignored. SVN is huge, and it is very complex to build and support from scratch (i.e. without pkgsrc). It effectively requires both Python and Perl, and often Ruby too (if you want to use many of the additional and often useful or even necessary tools). Its network exposure is huge, with all of the Apache libraries involved. Something else to note is that many of the FreeBSD folks are now reasonably clear that in choosing SVN they took the wrong path and for the wrong reasons (but they don't know yet how to really extract themselves from the mess they got into, though mirroring to github is now part of that process). BTW, that site svnvsgit.com is highly biased, and gives arguments based on false reasoning. They talk about scaling without identifying crucial differences between how SVN (and CVS before it) structured a repository vs. a "module" and in doing so make the false comparison between a Git repository and an SVN repository -- they're not the same thing at all. Try comparing the SVN vs. Git operations on something large, like the whole FreeBSD main source tree. Even on a limited desktop machine Git operations (especially common frequently needed ones) are far faster. Here's a fetch and pull from Github to my own local development server after not doing it in many weeks (since late January), so about 4200 changes pulled and probably over 1500 applied to the checked out "master" branch in the local filesystem: $ cd /work/woods/m-FreeBSD-src $ time git up Fetching origin master fast-forwarding... 121.73s real 7.20s user 273.77s system (Huh, I just saw a UTF-16 Byte-Order-Mark in at least two commit messages while looking at the log to count the changes!) The whole range of other more direct problems with SVN is of course the real issue with it: - not really doing branches properly or usefully - not doing or tracking merges properly - not really tracking changes per project (but rather per dir) - not being ACID in commit semantics - not being distributed and usable offline - not having secure guarantees of commit contents - being slow and a big resource pig (with a larger attack surface) CVS had/has all those problems too, except the last one of course, however it pays you back for them by not being a big huge monster, and it also gives you a very simple human and tool friendly repository structure (which is all too accessible if you don't heed warnings about messing with it in unsupported ways!). DVCS systems like Git and Hg make merging extremely easy and give powerful tools for many of the issues in merging because they MUST. Collaborating with a DVCS requires constant merging. Add branches to the workflow and now you've made the merging issues even more complex to the power of the number of branches you have, multiplied again by the number of distributed repositories you have. If Git or Hg didn't solve most of the issues that all that complexity brings then they would never ever be used. Throw in having a service like Github that has a magic "fork" feature to securely integrate work for disparate users and there's no contest to how well Git supports branches, merging, pulling, pushing, etc. More reading: http://www.laliluna.com/articles/2012/06/15/when-subversion-fails.html -- Greg A. Woods <gwoods%acm.org@localhost> +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpVixBgXgQjp.pgp
Description: OpenPGP Digital Signature