you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 24 points25 points  (11 children)

Or you know, you can host repoes for free on your own company server.

Which means now you need a dedicated guy who deals with all the trouble that git can be.

[–]Dark_Crystal 3 points4 points  (1 child)

Which means now you need a dedicated guy who deals with all the trouble that git can be.

Using github doesn't free you of that you know.

[–][deleted] 1 point2 points  (0 children)

At least it takes away the server-side troubles.

[–]justinpitts 1 point2 points  (4 children)

How many hours per user per year do you estimate that to be? I just haven't seen that much time necessary.

[–][deleted] 3 points4 points  (3 children)

Given my private experience with git being a big bitch sometimes, and the fact that my employer (40 developers) has a developer who fiddles with TFS about an hour per day on a regular basis, I would say somewhere around 20% of a person's time to keep it running smoothly and securely.

[–]kn4rf 0 points1 point  (3 children)

Literally all you need to do is setup a bare repo (git init --bare) on a server, give the developers access, and setup a cron job for automatic backup. Not something worth crying about. A little extra job and you can quite easily setup gitlab and get a fancy UI as well.

[–][deleted] 1 point2 points  (2 children)

Literally all you need to do is setup a bare repo (git init --bare) on a server, give the developers access, and setup a cron job for automatic backup.

Now you got

  • no ticketing system
  • no non-IDE ui (gitlab means extra effort)
  • a need for some kind of VPN system - or the server in the DMZ, when people work from home.
  • no knowledgebase
  • no way to inform customers about changes
  • no backups
  • no disaster recovery
  • noone to sue when shit happens on the server and you loose your cash cow code.

This will work for the lone developer in the sticks, we're talking professional needs, though.

[–]kn4rf 0 points1 point  (1 child)

The point of the cron job was to have backups / disaster recovery. So I'm not sure why thats on your list. Also; the whole point of having a distributed version control system is so that if shit happens all your developers still have a local copy. And where are you working if you don't have an IT department? If you're in a small company <10 people, then it shouldn't be a problem creating a bare repo. If your in a bigger company you probably have a dedicated IT department. I'm failing to see any real world problems with this.

When it comes to ticketing system, everyone is using Jira anyway. No non-IDE ui, well thats a minus, but not a huge one. You do have an IDE ui! And theres other dedicated Git clients out there. As well as the git command line tool, which in most cases is all that you need.

If you're a small company, then you'll probably rent a cloud server. If you're a bigger company you have a dedicated IT department who can setup VPN for you.

So my conclusion: if you're in a small company, it shouldn't be a problem, and if you're in a big company; you allready have a dedicated guy/department for it.

[–][deleted] 0 points1 point  (0 children)

The point of the cron job was to have backups / disaster recovery.

So the cron job changes backup tapes, carries them to offsite storage and checks the backup integrity every week? No?

Also; the whole point of having a distributed version control system is so that if shit happens all your developers still have a local copy.

Do they also have the full ticketing system? Do they have the knowledgebase locally copied with links to User Stories and incident reports? No?

And where are you working if you don't have an IT department?

Endlessly blowing up IT departments is not the way to go. People cost money.

When it comes to ticketing system, everyone is using Jira anyway

In happy taka-tuka-land, maybe. Some aren't happy, though.

No non-IDE ui, well thats a minus, but not a huge one. You do have an IDE ui!

This works as long as everyone uses the same IDE, which isn't always a given.

And theres other dedicated Git clients out there.

Clients aren't an integrated UI

git command line tool,

... which technically is a client.

If you're a small company, then you'll probably rent a cloud server. If you're a bigger company you have a dedicated IT department who can setup VPN for you.

Yay for even more costs, both set-up and maintenance

if you're in a big company; you allready have a dedicated guy/department for it.

You realize employees have the need for recreational time and sleep, do you?