4 ms·

1. are you worried about people spoofing someone else's commiter/author entries? 2. `git clone --depth` or use submodules. I agree that they're not very friendl

1. are you worried about people spoofing someone else's commiter/author entries? 2. `git clone --depth` or use submodules. I agree that they're not very friendly to use. 5. you can easily have a centralized place where everyone pushes 'master' with git 6. `git push --mirror` to some other place 7. you can have hooks on your git server too (for email, continous integration, etc.) 9. even with SVN I was using git-svn (and svk) before that purely for the offline commit feature, or having the ability to do more than one local commit at a time and push a tested set. In your case it wouldn't have made a difference whether your server was SVN or git, I would've still used svk or git-svn locally. Backups are important, have people run a daily backup on their workstations (like duplicity, but for a LAN even something like rsnapshot would work nicely). You might think SVN saves you until you find out that they forgot to 'svn add'/ a file (or whatever the equivalent was) and they mistakenly cleaned their source tree and now its gone for good.

cssmoo 12y ago
Some replies... 1. Yes. When you have 220 people to herd, some of whom are contractors, there is inevitably a probability of a bad egg or two. Human personalities don't scale well from direct experience unfortunately. 2. Will investigate. I think one of our guys tried this and found a number of shortcomings. 5. Until someone doesn't or someone pushes to someone else's repo who then pisses off on holiday (this happens so often on our git projects it's unreal - yes we have a few test git projects on the go as well) 6. Aware of that. However it pushes local branches too which introduces some interesting problems. 7. Yes but on every rev that gets committed? With git people work offline for days at a time and then push to master in one huge chunk and our pre-commit validation would go apeshit (it does a lot of analysis and validation so would result in massive blocking of work if you don't commit early and often). 9. You would have used what you were allowed to ;-) (I tried git-svn and had some problems but they weren't terrible I admit). Regarding backups of workstations, our workstations are disposable. It's not unusual (at least every 9-12 months) for one to get swapped or upgraded overnight with no notice or blow up and turn up with a base image. "meh" and 20 mins and you're back where you started. The mantra is "if it ain't on the fileserver or the SVN, it doesn't exist". Best to checkpoint your shit at the end of the day either by exporting a patch to the fileserver or committing on your feature branch. Nothing else matters really on a workstation and it needs to stay that way. Mainly cat herding issues to be honest. Edit: a final comment... You wouldn't believe how many ways there are to fuck up a software project with 200+ people on it. It's a warzone of competing ideas, personalities and politics. The only way to run it successfully is with an iron fist and strict control. That's probably a large reason why centralised VCS makes sense for some orgs.

cssmoo 12y ago

Some replies... 1. Yes. When you have 220 people to herd, some of whom are contractors, there is inevitably a probability of a bad egg or two. Human personalities don't scale well from direct experience unfortunately. 2. Will investigate. I think one of our guys tried this and found a number of shortcomings. 5. Until someone doesn't or someone pushes to someone else's repo who then pisses off on holiday (this happens so often on our git projects it's unreal - yes we have a few test git projects on the go as well) 6. Aware of that. However it pushes local branches too which introduces some interesting problems. 7. Yes but on every rev that gets committed? With git people work offline for days at a time and then push to master in one huge chunk and our pre-commit validation would go apeshit (it does a lot of analysis and validation so would result in massive blocking of work if you don't commit early and often). 9. You would have used what you were allowed to ;-) (I tried git-svn and had some problems but they weren't terrible I admit). Regarding backups of workstations, our workstations are disposable. It's not unusual (at least every 9-12 months) for one to get swapped or upgraded overnight with no notice or blow up and turn up with a base image. "meh" and 20 mins and you're back where you started. The mantra is "if it ain't on the fileserver or the SVN, it doesn't exist". Best to checkpoint your shit at the end of the day either by exporting a patch to the fileserver or committing on your feature branch. Nothing else matters really on a workstation and it needs to stay that way. Mainly cat herding issues to be honest. Edit: a final comment... You wouldn't believe how many ways there are to fuck up a software project with 200+ people on it. It's a warzone of competing ideas, personalities and politics. The only way to run it successfully is with an iron fist and strict control. That's probably a large reason why centralised VCS makes sense for some orgs.