I'm sorry. But you all forgot the one “source control” (in quotes, because it's barely worth the name) system: Microsoft Visual Sourcesafe.
Wow. That thing was horrible. It didn't have a network protocol. Network support was implementing by sharing the repository database over SMB. Of course that caused race conditions all the time, and committing a change had a potential risk of corrupting the source code database. Read that again: A source code repository that regularly corrupts its database. That's kind of the one thing you don't want your source control software to do. Not to mention the fact that using it over a slow link was basically impossible, due to the way the software accessed, I suppose, the entire database for every operation making a simple commit take 20 minutes or so in my case. Also, in order to edit a file, you had to check it out, and when the file was checked out no one else could edit it. That caused people to call their colleagues to stop working on a file and revert their changes because someone else needed to commit a change. If the person wasn't available you were screwed. I personally dislike Git with a passion, but I'd take it any day over Visual Sourcesafe. On Sun, 22 Dec 2019 at 22:45, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote: > Hi Blake, > > thanks. > > Ad 0. Actually there is a worse system: clearcase. Not sure if it still > exists. I still recall from > about 20 years ago, after travelling across Europe to attend a code > review, that I couldn't > see a single line of code, apparently due to missing "views", and > nobody was able to fix > that (the responsible clearcase admin was on vacation or so). > > Ad 5. I ran into exactly that problem. After to crowd moved to git, I > moved my (at that time > separate) SVN repos into one git repo with one subdir per SVN repo. > Reason was > dependencies between two of the repos that came up after the repose > were created. > Some other repos were moved into other subdirs of that same git repo. > After that, I got > millions of merge conflicts when co-workers pushed changes into their > directories. > It was often weeks during which I could not push my changes, and in the > end I had to > submitted my changes by email. In svn you can simply delete conflicting > dirs and > svn up will happily recreate them. In git this will send you into a merge > because the > delete is another change that wants to be pushed (which you can't due to > still > pending conflicts). > > Ad 6. You cannot commit empty directories in git. How stupid is that? I > know there are > workarounds to fix this, but why would you? I normally start a new > project with empty > directories: trunk, tags, and branches. Push them in git and nothing > happens. At that > point your local build may succeed while a fresh check-out of the same > repo will fail. > > Best Regards, > Jürgen > > > On 12/22/19 12:34 PM, Blake McBride wrote: > > I couldn't agree with Jürgen more! > Although I agree that GIT has become the most popular, having used both > GIT, SVN, and others, I can't imagine a worse system than GIT because: > 1. What? You can change history?!? > 2. Although I have a very long career, have learned many systems, authored > a computer language (Dynace), I am clearly not smart enough to understand > GIT. Many times I have gotten myself into a mess with GIT (never with SVN). > Interestingly, not even the "experts" could help me with GIT problems. Err. > Try this, try that. I can't even understand its history. > 3. I like a central point of truth and think it is vitally important. > 4. When cloning you get every change since day one. That's nuts! It takes > forever to clone a large system. They seem to have the philosophy that disk > space is free but the Internet is not always available. I prefer the > philosophy that the Internet is always available (or available enough) and > disk space and my time are not. > 5. GIT forces you to keep separate projects in separate repos. How do you > keep them in sync? SVN doesn't have this problem. > The bottom line for me is that SVN is far, far simpler, and it has a > better model. > Blake McBride > > On Sun, Dec 22, 2019 at 4:40 AM Dr. Jürgen Sauermann < > mail@jürgen-sauermann.de> wrote: > >> Hi Peter, >> >> since GNU APL is hosted on Savannah, I suppose you can use git already if >> you want: >> >> https://savannah.gnu.org/git/?group=apl >> >> or: >> >> git clone https://git.savannah.gnu.org/git/apl.git >> Regarding myself, I'd rather die before using git. My last employer tried to >> make me change from SVN to git (the argument being that I was the last >> SVN user in the company) and I decided I'd be better off enjoying my >> retirement >> rather than wasting my time messing with git problems instead of programming. >> My obvious aversion against git is based on quite some working experience >> with git. Even though I am using SVN since 15 or so years (compared to 3 >> years >> git) , I have in total spent more time on git (-problems) than on SVN >> (-problems). >> >> Best regards, >> Jürgen Sauermann >> >> On 12/22/19 3:15 AM, Peter Teeson wrote: >> >> GNUApl seems to me to be pretty stable at the present time. So I’m wondering >> what people think about the following: >> >> My sense is that Git is the version control system of choice these days and >> has pretty much replaced SVN the way it replaced CVS. >> >> There is git-svn module which provides bi-directional maintenance >> capability. In particular will preserve in git the historical svn commit >> meta data if desired. >> >> Similarly github has replaced sourceforge for collaborative project >> repositories. >> >> Been working with both git and github for a couple of years now and wonder >> how folks feel about moving to them? >> IMO I think it would be a good move to future proof the source since I think >> very few people are learning svn anymore. >> >> Comments? And yes I’d be willing to take a shot at it. >> Not just out of curiosity but with the intention of switching for the >> future proofing reason at some cutoff date. >> >> respect…. >> >> Peter >> >> P.S. Learning the basics of git are not too difficult and there are lots of >> good tutorials as well as the git book which is freely downloadable. >> >> >> >> >
