|
The part that had me confused is that ultimately, all code *must* go back to the main server - just like SVN. What I did not comprehend is that when you pull a project from a GIT repo it's almost as if you copied the repo to your local machine. Once you push your changes back to the server, the magic of software kicks in, there is smoke and flashes of light and it all gets put back together.
I'm not sure if that justifies hyperventilating over GIT, but I understand the subtle difference now.
as other's have commented, it was born of distributed open source development. I live in a proprietary internal network with fiber everywhere, so I just did not see the "glowing" points for GIT. At the end of the day, it's just another source control system.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me.
I say this as a dude who used SVN for years...
- Git is awesome.
- Old crusty people refuse change and to continue learning.
- People need to embrace distributed concepts if they want to belong to the future.
Now, as far as why you care today, as in right now. This is really a conversation between centralized vs distributed. You can replace SVN with anything centralized.
- Unlike with SVN, you can be 100% offline and still commit code you work on. Yeah sure, you can set up a local SVN server on your home network, but let's be real. This mean, if you commute to work on a train, you can code away and make commits. Then push them to a remote later on. If you never go outside, less of an issue I guess.
- Run queries and searches against your entire repo's history, locally and quickly.
- Run hooks to gate/guard your code before it ever hits the real repository. Yeah sure, you can have staging/feature branches in both Git and SVN, but with SVN it's still in the remote repo.
- Under the hood, git diffs commits more efficiently. I don't have evidence for this so it's anecdotal. But, from years of using it, it just feels quicker.
- I haven't used SVN in a while, so maybe this is moot, but with Git you have Git LFS. Google it.
- You should be making frequent commits to code. SVN is too slow for this. Large commits are terrible for maintenance. Anyone working in a large team knows this.
- Git is profoundly better at handling branches and deltas than SVN. Granted, I haven't used SVN in years... maybe it's better at it now... maybe. I don't know.
Anyone on CP saying keep with SVN, I can promise you still uses jQuery or VB, sans a few. And there are people (except for one, shout out to Ravi) who will argue all day long about how they think they are experts in their choice of version control, but they can't read a post or explain anything simply. Point is, don't trust CP to give you the best info always.
Oh, and sorry, if I sound jaded. It's not you or your post, I promise.  I'm just old and cranky and really tired of having to deal with certain types of peeps, that's all. 
Jeremy Falcon
modified 13-Feb-24 9:09am.
|
|
|
|
|
"Old crusty people refuse change and to continue learning."
Now be nice.  . You also seem to be a bit bitchy this morning. There was no intent to start a cat fight.
My question was serious, as all of the articles extolling the virtues of GIT vs. SVN leave me picking my nose and pondering their argument. Old crusty people tend to run development groups and what not, so before fragging the dev process, there needs be justification.
My post was not a GIT sucks question - I actually have only tinkered with it. Since VS2*** has buried it into the menus and behavior, I thought I might learn something.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: You also seem to be a bit bitchy this morning. There was no intent to start a cat fight.
You're right, I swear it wasn't you or your post. I'm just holding on to crap from a ton of bad experiences on CP.
Jeremy Falcon
|
|
|
|
|
upvoted.
All I care about is source control and the release process. Trying to understand the next great thing.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
As a former user of SVN and VSS the difference for me is that its branching model makes it much more (but not perfectly) clear what's going on and where my branch fits into the project, and not having to deal with locks.
And I must say Visual Studio's git interface is the bee's knees and one of its best features.
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
I personally felt that branching and merging, accompanied with reviews in one toolset like git hub is way better than SVN.
But to be honest, I haven't looked into SVN for at least 6 years and even back then i did all relevant things with JetBrains tools, so i only have to use SVN to push and pull code.
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");
|
|
|
|
|
Branching is much easier, it does not create any additional directory since it is a pointer to a specific commit. The way branches are managed make following the timeline of modifications a lot easier for merging purposes.
We used it for an ECU with a main codeline + different features to be added + different parts of the code to be ported to another OS + different stages of development for every customer. Managing that amount of branches with GIT is easier. EG tyipical workflow in GIT was:
* branch from current main or current stable (first thing I do before touching the code)
* get a feature to develop from Jira / Polarion / Redmine
* Start developing the feature
* [...] Several commits and pushes
* Eventual side-branches for different potential solutions / potentially breaking code changes
* Commit "working solution"
* Pull request to Integration
* Branch from current main or current stable
* Get another feature to develop
* Repeat as necessary.
Integration will then merge all open branches in the new main or stable line and stop + reject PR if some branch causes failures to compile, otherwise regression tests and validations are peformed and main or stable is advanced. Now everything shall start from main again.
For one developer it's useless, for 4 developers in the same office it's overkill, for 300 developers across the world it's sanity. Nothing ever gets removed from GIT, ever (unless some idiot with permissions forces it) so a stable, working commit is always reachable.
One thing I loved about git was that it doesn't need a server, any file-system works, so when I worked for B***h I actually cloned the repo on my network, worked locally from my PC to the local repo then send only the vetted commits to the company repo. It allowed me a lot of flexibility, mostly that of using my own computer to edit the code while I would have been mandated to use only their horrible workstation with only a handful of useless programs (writing code in Keil is painful).
In my current company we use SVN, we are literally 5 developers in a office and SVN is also used as a shared storage for documentation and stuff that should not be there. Many systems in the company refer to that SVN so we won't change - except that we can only have a total of 20 users otherwise we'd have to change license for the SVN server and we actually are at capacity since there are (stupidly) other people accessing that repository, and we can't have more than one repo due to licensing.
Any serious company still uses some form of server for GIT anyway for permission management (you don't want to give rebasing permissions to any developer unless you want a broken repo).
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
We do all the branching / dev / commit / merge to integration just fine with SVN. I simply fail to see the superiority of git in this regards. But read my comment to the entire thread.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Okay, based on Jeremy's and other comments, I think I may be close to understanding what GIT does better than SVN or any other centralized server system...
When a developer wants to do work, they pull a working copy. It's local to their machine. All of their work - commits and what not occur to the local copy. The changes do NOT go back to the repo until they push. When they push, the code changes, the history, etc go with the push.
Do I have this correct? Going to go read some GIT doc.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
modified 13-Feb-24 10:08am.
|
|
|
|
|
charlieg wrote: Do I have this correct? Going to go read some GIT doc.
You are 100% correct.
Jeremy Falcon
|
|
|
|
|
charlieg wrote: The changes do NOT go back to the repo until they push.
Oh, I'd also add to that, that in git-land, to help untrusted code not make its way into the mainline and since merges happen like crazy (a good thing), a pull request is a common thing. So, if someone pushes a change to a remote repo, you could set it up to require a code review. You can technically do this in SVN-land, it's just more of a pain to pull off.
Jeremy Falcon
modified 13-Feb-24 12:28pm.
|
|
|
|
|
Sounds like how I work.
I tool away for a couple of days; if I was on the right track, I compile, zip and save that version to a remote drive with a dated file name. Or start over.
Repeat evey few days.
No branches, twigs, leafs, buds, flowers, weeds.
Sort of like how we did backups in the "old days". Except there are no carts with card trays or portable disk packs.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I guess. Except we're all driving around in Teslas and you're Fred Flintstone in your feet powered car
|
|
|
|
|
For one man teams that are diligent, it can work. When you get to more than one, it rapidly gets out of control.
I still remember the day when I was cleaning up the project folder... and I purged all the versions. I had no idea. He almost had an aneurism... took a few deep breaths and explained to me why he had a twitch in his eye  It's not like I was on a mission, I was trying to help free up some disk space we needed...
So, there I was with this "I just took a bite out of a ****-sandwich" on my face. Took a deep breath and said, "let me pull the backup tapes..." Thankfully they were from the day before and good. This was the day I had a career epiphany - delete nothing. Move it, archive it, but delete be bad.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I am not a big fan of Git but that's what we use. I guess the good news is GitHub is not the sole provider of the service - there are others such as BitBucket which what we use and it integrates with VisualStudio reasonably well.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
See that's the other thing. I would NEVER have company code out on GitHub. Source code is the Crown Jewels and the jewels stay on the premises. I do know you can set up your own server locally, or I think I read about that.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
GitHub does allow for private repos btw. If that's the concern. I mean, the code is still on their servers though, but at least it can be marked as private if desired.
Jeremy Falcon
|
|
|
|
|
Github is not just public repositories, it makes most of its money by hosting private repositories.
You can use other services like Azure or Bitbucket.
Or even self host.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
sorry. Microsoft bought GitHub in 2018. Microsoft is the "most public" fluster cluck of security that I can even imagine, not that they are alone. I'd not trust HP nor Amazon with the Crown Jewels.
I want that one person or small group in my company understanding they are not going to lose a contract, they are going to be summarily terminated for not doing their job.
It's down toward the bottom of the list to research - offsite GitHub repositories, but every fiber of my being says no. If I could put a private GitHub repo behind my firewall and on my network - fine. Companies hosting this out in "the cloud" are out of their elephanting mind.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: I do know you can set up your own server locally
You certainly can - I have a Git server on my Synology NAS as a local backup, and I've had a locally installed instance of Gitea in the past.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
charlieg wrote: Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not
The origination of GIT was specifically aimed at online open source projects.
Git - A Short History of Git[^]
The only significant problem I have encountered with git is that it does not work well with Enterprise development.
In an ideal Enterprise world one would have the following
- Strict boundary breakdowns
- Teams working on libraries
- Applications using libraries by version
For git the above works well because a library is then just a repo. And a deliverable.
However that ideal is not what happens. Even modestly sized business multiple applications (product or service is still an application) are a norm. With SVN that works as follows.
- library code goes into its own folder tree
- Apps each go into their own folder
- An app folder and associated folders is labeled for a build.
The means that the library code moves forward but it is labeled independently for each app.
It is NOT possible to do the above with GIT. There is one label for the entire repo.
So one often ends up with a mix of idioms. Perhaps one library in its own repo. But other libraries might be copied. Or two or more apps end up in the same repo.
And a repo explosion without tracking can also occur. Where one offs end up in their own repo.
With SVN it would just go in a new folder. Of course people will complain that that last case is a problem. So it is. But creating new GIT repos every single time without any coherent tracking is also a problem. (I have seen developers create repos just to experiment and then the repo gets abandoned.)
---------------------------------------------------------
As for losing source control due to problems with a specific source control solution ...
Long ago losing databases was also a problem. Forums would always have someone asking how to restore corrupted databases. That was true for every database vendor. I haven't seen anything like that for years. But also true that now people always back up their databases.
Source control is NOT a back up. But many places treat it has such. Even now.
|
|
|
|
|
I am hoping the use of sub modules will solve this.
One repo for the Solution, it just tracks all of the other required repos (libraries) at the needed release levels.
|
|
|
|
|
"source control is not a backup"
true words. But I have it on IT's assurance that they are imaging the VM server hosting our code. Years ago, I submitted an IT ticket to verify our backups. This created a tornado of panic. What do you mean the backup is bad? No, I asked you how do you know it's good.
As for your other comments about libraries and common code bases, well I gave up on that 10 years ago. ctrl-c/ctrl-v is our inheritance process  I'll admit that we're a very embedded product oriented shop, but I'd still like to see common code isolated to one area. Like I do, but I lost that battle long ago.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: Like I do, but I lost that battle long ago.
Did you mention due diligence and legal costs associated with copyright violations?
I like to point that out when someone complains because I insist the find the license. That due diligence comment really makes C level execs perk up.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
