>We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command.
You can configure your server to not accept certain commands and restrict pushing branches to certain users. Also if you do wipe your repository, restore it form your backup.
What backup? You mean we have to manually back up this system? Why should we have to spend money (aka devops man-hours) developing a backup system, when other Source Version Control systems don't let individual coders blow away the Source?
EDIT: For those unclear, we almost had to pull our backup of Source out of Glacier because someone deleted our local repository. We weren't expecting to need to set up permissions for things that should be assumed out of the box.
What backup? You mean we have to manually back up this system?
I am aghast at hearing you say this. Yes, of course you have to run backups. Like with everything else important on your systems.
Why should we have to spend money (aka devops man-hours) developing a backup system, when other Source Version Control systems don't let individual coders blow away the Source?
You don't have to spend 'hours' backing up a git repository. We typically use a bare git repo for the central point that is pushed to / pulled from by the individual developers. It is just a bunch of files, and so can be backed up easily.
You really don't sound like you know what you are doing.
I suggest you hire an experience system administrator (not just another devops) that understands the importance of backups.
I understand your gripe (though I don't agree with it; TFS comes out of the box with permissions that only allow administrators to force push in a way that rewrites history, but more importantly, this data was never lost, you would only need to look in the reference log to find this), but surely you're not seriously suggesting that one not backup their TFS server? Please do back that up, even if you're using TFVC moving forward!
Are you telling me that you don't backup anything? You just expect the version control system to (e.g.) magically recover itself from a hardware failure on your server?
It's a version control system, not a backup solution, in the same way that RAID-5 is not a backup solution.
"Backup" is not a component of revision control software. If one has such 'backup functions' they're just window dressing.
What you must be talking about (well, I hope anyway) is the capability of a revision control system to be backed up on the fly, similar to the tools used to backup a live subversion repo without causing corruption. Git has such functionality; simply do a fetch from a remote repo, then backup the result.
If you're expecting revision control systems to include some sort of "backup suite", sorry, this is *NIX, not Microsoft. The tools do a particular job and it's up to you to plug that into your infrastructure, including your pre-existing backup infrastructure, which i'm sure your company must have. It would be laughable if they didn't have backup infrastructure already.
I've seen a company with contracts guaranteeing 100% uptime, while running things off of a single MS server with no backups. It's entirely possible for software companies to be this stupid.
> It's like a RAID-5 where you have to tell it to rebuild a new disk.
Well, you do have to give it a new disk first, right? Or do you expect the RAID-5 array to automate the process of purchasing and installing a replacement disk?
> Also if you do wipe your repository, restore it form your backup.
Git is distributed. The "backup"† is another dev doing a git push -f. Also, git reflog. The argument just does not hold water. (Also, do backup your VCS server anyway.)
If you want to keep rogue devs in check, set up a Gitlab instance, and use protected branches and merge requests.
† Read me correctly, it's not a backup, it's just part of the resiliency of git. Proper backups should be made il all cases.
Everyone else only has a full copy of the repository if they actually check out a copy and keep it local. That's apparently not how my coders do their workflow.
The most usual way to work with git is to pull a local copy of the whole server using "git clone"[1]. The only way to do a partial copy would be to do a shallow copy locally with only the last few commits, but then it will probably be harder to merge back... So it seems you are either wrong, or that your team is using a very very exotic workflow.
[1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
If all your coders are editing files in one single directory all at the same time, well, that's pretty crazy. Not even CVS forces you to all work out of the same directory; it lets you check out your own local working copy and push changes to the server. Git is almost the same from the user's perspective, with the noted difference that you get an entire copy of the repo and not just one working copy of some of the files.
Going by the rest of this thread, I wouldn't rule out the possibility that they are doing something insane like committing multi-gigabyte objects regularly, and then only checking out with a low clone depth.
I've seen people attempt that before; without fail people who are deeply in centralized version control land and do not bother to understand git before attempting to switch to it (because it is trendy, or because people under them won't stop complaining about using svn in 2014).
You can configure your server to not accept certain commands and restrict pushing branches to certain users. Also if you do wipe your repository, restore it form your backup.