The Lounge - CodeProject

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 Smile | :)

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 Frown | :(

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.

" copyright violations?"

Please elaborate, I'm not following you. All of our code belongs to us.

As for your description of enterprise level development, holy cow, I've not done anything like that in 20+ years. Thinking back to when I did gave me a headache Smile | :)

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:
All of our code belongs to us.

So your company does not use 3rd party libraries of any kind?

Only time I have heard of that is significantly intense DOD work.

Okay, I follow you now. They tend to hide behind other vendors if they are spending $$. But the developers tend to play around, and licensing of this sort is so far off the radar...

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.

Agree 100% on the license. Especially with the older licenses. Include and enhance the wrong “open source” component and you might have to disclose your whole product.

Also the free for development but pay for production licenses can bite you.

Yes I have seen both of those also.

I was using SVN briefly when I was on first job after university so I might not remember it correctly but I remember frustrations it was giving me and I hated it with every piece of my body. Using GIT was a breeze and I instantly got the mental model, so I might be biased for using it for last 14 years and remembering SVN workflow as workflow from hell. So I have a lot to write on the topic - because I feel that GIT is just so much better and it makes me much better developer and development so much easier.

Let's start with not needing connection to the server to be able to create commits. When internet is down I still can create commits move them around and publish to server when I want not when SVN wants. Also if I have it locally it is much faster to commit anything than over the network. (almost no one uses fully distributed workflow so yeah)

Branching is something you just do in GIT and you don't have to ask anyone because branches don't live on the server. I can do 10 commits then go back to starting point and make new branch in matter of minutes and have different approach developed, I can delete local branch that I don't like and publish stuff I do like. No one will ever see it.

Conflicts, I can fetch changes from remote repository and have my local branch separate, I can keep on working on my stuff until I want to merge things while also having possibility to easily switch to. With SVN I am forced to deal with stuff even when I am half way done but I also want to check what is there so I could prepare for it.

In general mental model for having undo outside code editor that I can view and cherry pick, staging chunks of files to move parts of my development outside of IDE - because some things can be added by IDE and I can control what I publish in perfect way gives me ease of mind. Where SVN tooling was rudimentary at best, maybe it changed as I not used it.

"Let's start with not needing connection to the server to be able to create commits"

This is the key difference that is NOT well explained when comparing GIT to SVN. The fact that you can have all of the source control actions local including comments and what not falls under what I would call a "useful feature." Smile | :)

In my shop, any developer can create branches and tags and have done so for years. So, when people say "branching is a breeze in GIT as compared to SVN" no brilliant flash of the obvious came to mind. The only thing that MUST be done as an admin is to create a new repo.

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.

Yeah that is for me "distributed" part that is basically killer feature.

Unfortunately people throw "distributed" around like everyone should be mailing patches to Linus himself and other contributors just like it is some holy grail - but no one uses it like that so everyone only gets more confused.

With git, you get two vcs for the price of one. You have a local one and probably a remote one.

At work asking for a repo was heavy paperwork.

With svn I had no opportunity to put my small projects into version control.

With git I can create a local repo without involving paperwork or someone from the sudoers group.

In git, the master repo can be protected by using pull requests instead of just giving rights to push into the master repo.

to be fair, that's not an svn issue - it's a process issue. For our SVN server, you want a repo, we RDP in and make a repo, though I see the point that it's a manual operation. We don't have a lot of developers just wanting random repos, so valid point.

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 an application operator, so I do not have Administrator / root rights anywhere, I don't have remote login rights, etc.

With centralized VCS, I need a sudoer to create a repo.

With git + TortoiseGit, I can make a local repo anywhere, and at least track my scripts.

This is centralized vs. distributed, svn vs. git.

(At home I use svn, because, as we say here, everything is beautiful at home, 6 cores, 12 threads, 32 GB of RAM and sudo rigths Wink | ;)

)

I used to use SVN years ago. I recall there were a few minor annoyances, but by and large it was a good bit of kit, and TortoiseSVN was a good UI. In more recent years I've used Mercurial. Like Git it lets you have one (or many) local copies of everything on the server, which can be handy for speed or if you might have periods where you can't access the server. It also means that if the server catches fire, there's a fair chance people will have a copy of the source code somewhere. TortoiseHg has Mercurial covered. It's a good UI and like SVN, things work pretty smoothly most of the time.

Fairly recently our team moved to Git. So far it seems very much that "Git" is rhyming slang. The Tortoise offering offers far less for Git. There are a lot of Git UIs out there, but it's tough to find a good one, especially if it needs to be free. Visual Studio does sort of okay on that front. As a result, I do a lot on the command line when using Git. Git's concept of branches, to me at least, seems far weaker than Mercurial's. It just seems to keep a record of the latest changeset for each branch and keeps a record of the parent changeset. Finding your branch's parent branch is at best tricky, at worst impossible. For me, Git has few if any advantages over Mercurial, and as a bonus has an unpleasant learning curve and unnecessary complexity. The whole world apparently disagrees with me, but I wouldn't recommend it to anyone as long as Mercurial is available. But if SVN is serving you, there's no shame in sticking with what you know, either. You could give Git or Mercurial a test drive on a personal/mini project if you want to see if the grass is truly greener (spoiler: with Git, it's less grass and more wasteland with bonus fly-tipping).

Subversion is not distributed. What this means practically is that there's no command like "git push", and this means that committing requites a working network connection to the source control server.

You can't rewrite history, because every commit immediately goes to the server. You can't commit when not online, so you're forced to be on a reliable connection if you want to have small, clean commits. And if the upstream subversion server dies, the history is gone, where with git, every client that clones with the default options has a full copy of the history.

There are other subtleties, but the above are a large part of why got was created for and adopted by Linux kernel maintainers by Linus himself.

------------------------------------------------
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing

Which is stupid.

Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY

Git is an excellent tool for a very specific use case that 99.9% of projects don’t fall into. It’s great if you have a massive source base with many geographically dispersed contributors who don’t always have reliable Internet connectivity. Vastly overcomplicated, IMO for anything else.

Welcome to the Lounge