Here is the thing for me. In the beginning, I read a little bit about subversion. Its model, at least from a user's perspective, was simple and straightforward. I was able to make use of it immediately. As my needs expanded, I found simple solutions with subversion. I never got caught up in a knot.
When GIT came out, I too was excited about using this great new tool. Getting the basics down was easy, and I got it all up and running trivially. However, as I used it, I sometimes needed to do something a little less common, or I needed information out of the repo that I had difficulty finding. I read several books on the topic. It seems that at its heart, GIT is a key/value pair database. Try as I might, I could not reconcile the theory with its use. When I got myself in a mess with GIT, I requested help from the local "GIT expert." However, more often than not, they couldn't figure it out either. I have owned a few software companies over the years. In the more recent (20) years, I've always used subversion. It is simple to understand and does what I need. Many times I have done work for other companies. Especially in the last 15 years or so, everyone seems to use GIT. And during that time, in every case I can think of, I've had problems with GIT. Given this experience, I have asked several people why they use GIT. Although I get a variety of answers at first, when I probe deeper, the answer always seems to be "because everyone else is using it!" So, my conclusion is the following. If you work for others and want to maximize your opportunities, it's best to use GIT because that's what they're hiring for. However, if you own your own business and need a practical solution that does the job with minimum expense and hassle, you use subversion. Blake On Fri, May 26, 2023 at 7:29 AM vvs <vvs...@gmail.com> wrote: > On 5/26/23, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote: > > I would like to share another anecdote with you. > > Thanks for sharing. Now we have some experience in common and not only > in technology ;) Sorry that it happened to you. I believe that such > society is broken, but that's another matter. > > Git has a distributed store. That means that every user has a server > of their own. What happened on your server will be therefore > replicated to others. But they are not obliged to get your changes, > that's part of a project workflow. In your case this is what your > company did by requiring that all employees should commit into the > same branch. That's fine as long as there are only few trusted parties > which wasn't actually the case. It wasn't you who should be fired, but > it's your manager who certainly should. > > So, I think that your mistrust in Git is actually misdirected. You > shouldn't trust your company' workflow here, that's what was broken. > Consider what might happen if they would put inexperienced admin to > maintain your company' SVN server? What if he would corrupt it' > repository? Should SVN be held responsible? BTW, in your case it was > just a matter of reverting that single bad commit, the repository was > actually intact and safe. The data were not lost due to a mistake! > > BTW, I did put "complexity" in quotes and added an emoji to indicate > that an irony was intended. I don't think that SVN is too bad, it was > my own inexperience that got me in trouble. > > P.S. There are big projects that use hundreds of short living branches > to coordinate work of dozens of developers for many years. They have > huge repositories and a good workflow. Git saves them expensive > storage space, valuable time and network traffic in their work. It > makes a one-time contribution very easy for volunteers. Check out > NixOS for example. But it's not a silver bullet and it can't prevent > shooting yourself in the foot. Neither could Subversion or any other > software. > > Have a nice day > >
