4 ms·

Unpopular opinion here but we're using SVN here on a large project. No intention of changing it. Why? 1. Deterministic "whodunnit" as we have AD integrated wit

by cssmoo 12y ago

Unpopular opinion here but we're using SVN here on a large project. No intention of changing it. Why? 1. Deterministic "whodunnit" as we have AD integrated with. That is needed when you have 220 people using a repo. 2. Partial check outs. Our platform is 6MLoC in total. 3. TortoiseSVN. Sorry there's nothing else out there as good as that. We use it for DMS tasks as well as you can merge word docs etc. 4. Binaries and locking. Works for design workflows and the odd file we can't merge easily (git/mercurial aren't magic bullets for that). 5. Centralised. All our shit is in one place so there's a "single source of truth". Also no patches flying around. 6. Easy to backup and replicate. Svndump into single file. Or svnsync and there's a true copy. 7. Perfect tooling/tracking integration due to the centralisation and hook support. 8. Easy to use for mere mortals (excel/word pokers). 9. Forces backup behaviour. A specific case but we had a couple of people using git and then pushing to our svn. One SSD fail and bang, the guy lost a week of work because he didn't push to master. Merge tracking is a non issue since 1.7 and if you need to work offline, just create patches and check them in when you're back online. Also our svn instance has been down for 3 minutes in the last 8 years... I really can't justify a move to a DVCS and lose all the above so I'm quite happy with my sanity.

edwintorok 12y ago
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.
marcosdumay 12y ago
> 3. TortoiseSVN. Sorry there's nothing else out there as good as that. TortoiseHG and TortoiseGIT are good contenders.
- cssmoo 12y ago
  On paper, yes. In reality, they're really nowhere near TSVN in reliability, documentation, flexibility and integration.
phaemon 12y ago
I am honestly baffled by your points 1 & 2. You have 220 people working on 6MLoC and you think git can't handle this? You are aware that git is used for the Linux kernel, right? I mean, it must be its most famous use case.
- ufo 12y ago
  1) Unlike the linux kernel, cssmoo's project has lots of large binary files. If he used git the repo sizes would blow out of control and designers would lose the ability to lock the files they are working on (locking is important because you can't merge binary files after the fact) 2) His organization is very different than what the Linux kernel does. Linux operates in a hierarchical manner where each subsystem has a maintainer that collects patches and sends them up to Linus. This system makes full use of Git's DVCS capabilities but its not perfect for everyone.
- s73v3r 12y ago
  Git specifically does not allow partial checkouts. I can't check out a subset of the source tree.
gcb0 12y ago
gotta live how the ONLY reply that agrees with the article it's full of borderline-trolling replies doing exactly what the article call out. gotta love HN hive mind! it's basically: > > I'm using that and it satisfies all my needs. > but if you join the hive mind you can do all those much more complicated and futile work around steps and get the exact same result.

by cssmoo 12y ago

edwintorok 12y ago

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.

marcosdumay 12y ago

> 3. TortoiseSVN. Sorry there's nothing else out there as good as that. TortoiseHG and TortoiseGIT are good contenders.

cssmoo 12y ago
On paper, yes. In reality, they're really nowhere near TSVN in reliability, documentation, flexibility and integration.

phaemon 12y ago

I am honestly baffled by your points 1 & 2. You have 220 people working on 6MLoC and you think git can't handle this? You are aware that git is used for the Linux kernel, right? I mean, it must be its most famous use case.

ufo 12y ago
1) Unlike the linux kernel, cssmoo's project has lots of large binary files. If he used git the repo sizes would blow out of control and designers would lose the ability to lock the files they are working on (locking is important because you can't merge binary files after the fact) 2) His organization is very different than what the Linux kernel does. Linux operates in a hierarchical manner where each subsystem has a maintainer that collects patches and sends them up to Linus. This system makes full use of Git's DVCS capabilities but its not perfect for everyone.
s73v3r 12y ago
Git specifically does not allow partial checkouts. I can't check out a subset of the source tree.

gcb0 12y ago

gotta live how the ONLY reply that agrees with the article it's full of borderline-trolling replies doing exactly what the article call out. gotta love HN hive mind! it's basically: > > I'm using that and it satisfies all my needs. > but if you join the hive mind you can do all those much more complicated and futile work around steps and get the exact same result.