I just joined a new team (very small: four developers in total, with two of those leaving soon). The two original developers set up the git repo on a folder in a Windows network share.
Am I taking crazy pills, or is that a bad idea? Our organization does have github/gitlab/bitbucket available, so is there any good reason not to use those hosted solutions?
Do you mean a bare repo you use as a remote and push/pull from or using the workdir straight from the share. The first would be strange, but kinda usable (don’t do this though), the latter is oh my god, get an other job category.
Working from the network share - I’ve worked on a project like this before, it was awful for developer experience. It took seconds to run a git status, it was so slow. Occasionally git would lock itself out of being able to update files, since the network read/write times were so slow. Large merges were impossible.
The reason it was set up like this was that the CEO had the network share we were working off of set up to serve to a subdomain (so like, Bob’s work would be at bob.example.com), and it would update live as most hot-reloads will do. He wanted to be able to spy on developers and see what they were doing at any given time.
I have a lot of programming horror stories from that job. The title of this thread brought up a lot of repressed memories.
my team had issues when IT accidentally changed permissions on the files inside a bare git repo located on a file-share. Otherwise it works okay as people clone and work locally. Not the best solution but we’re working around restrictions that makes this the easiest thing to do
With github, gitlab, etc etc, you get much more than just a bare git repo store.
My suggestion is to look at the features of each hosting solution and present those features to the team, discuss the pros and cons, and let people decide what they feel is best for the team.
Remember, you’re not proposing a simple version control system. You’re picking one very important part of an internal development platform: issue tracking, version control, code quality, security scans, developer workflow helper apps, documentation/wiki, build systems, etc etc. Depending on what you already have in the roles other than version control may inform your decision on where to host your git repo.
I would have to agree on this, it seems rather odd if the code repo is confidential or classified to be shared on a Windows Share. The reason why we would use Git services (self-hosted) is so that we have multitude of security services/layers maintained by dedicated team of system administrators such as firewall, service update, data redundancy, backup, active directory and so forth.
I can see a scenario where people accidentally put classified repos or information that aren’t supposed to be shared on Windows Share where unauthorized users could view that repos.
I don’t think this is too bad, but the question here is why they set it up this way. Are there any restrictions like no SSH? Also, this would make it hard to clone from an off site location (for remote work).
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@beehaw.org
All things programming and coding related. Subcommunity of Technology.
Do you mean a bare repo you use as a remote and push/pull from or using the workdir straight from the share. The first would be strange, but kinda usable (don’t do this though), the latter is oh my god, get an other job category.
Working from the network share - I’ve worked on a project like this before, it was awful for developer experience. It took seconds to run a
git status, it was so slow. Occasionally git would lock itself out of being able to update files, since the network read/write times were so slow. Large merges were impossible.The reason it was set up like this was that the CEO had the network share we were working off of set up to serve to a subdomain (so like, Bob’s work would be at bob.example.com), and it would update live as most hot-reloads will do. He wanted to be able to spy on developers and see what they were doing at any given time.
I have a lot of programming horror stories from that job. The title of this thread brought up a lot of repressed memories.
my team had issues when IT accidentally changed permissions on the files inside a bare git repo located on a file-share. Otherwise it works okay as people clone and work locally. Not the best solution but we’re working around restrictions that makes this the easiest thing to do
Still a better version control than
20210131_v0.2_test2_john20210131_v0.2_test2_john_final_final2_final_realWith github, gitlab, etc etc, you get much more than just a bare git repo store.
My suggestion is to look at the features of each hosting solution and present those features to the team, discuss the pros and cons, and let people decide what they feel is best for the team.
Remember, you’re not proposing a simple version control system. You’re picking one very important part of an internal development platform: issue tracking, version control, code quality, security scans, developer workflow helper apps, documentation/wiki, build systems, etc etc. Depending on what you already have in the roles other than version control may inform your decision on where to host your git repo.
Do you mean “cloud services”? Maybe your colleagues don’t want them there.
For PCI-DSS relevant code, we only use internal systems.
I don’t see how would this be compliant with literally anything.
I would have to agree on this, it seems rather odd if the code repo is confidential or classified to be shared on a Windows Share. The reason why we would use Git services (self-hosted) is so that we have multitude of security services/layers maintained by dedicated team of system administrators such as firewall, service update, data redundancy, backup, active directory and so forth.
I can see a scenario where people accidentally put classified repos or information that aren’t supposed to be shared on Windows Share where unauthorized users could view that repos.
I don’t think this is too bad, but the question here is why they set it up this way. Are there any restrictions like no SSH? Also, this would make it hard to clone from an off site location (for remote work).