4 ms·

The big risk I always see with git is that you start storing more and more work locally. This exposes you to the chance of hardware failure on a desktop pc. W

The big risk I always see with git is that you start storing more and more work locally. This exposes you to the chance of hardware failure on a desktop pc. With svn, it would be easier for the hardware to be redundant and backed-up.

jarin 16y ago
It's not hard to push topic branches to origin and delete them when they're done (although admittedly the syntax to delete a remote branch is a little strange). Just because the user has a risk of doing that doesn't reflect badly on the tool, though. It's like saying that the big risk of a knife is that you'll cut yourself if you're not careful.
jevinskie 16y ago
I fail to see your point. Every copy of a git repo is a full copy [1] - unlike a svn checkout. If you follow a centralized server model with git you have a copy on the server and every workstation it is checked out on. With svn, the full repo only exists on the server. Why couldn't you have a redundant, backed up central git server? [1] Not a substitute for real backups of your repo!
- edabobojr 16y ago
  Whenever people talk about git, they seem to talk about how you can have all of these working copies locally. My concern is the frequency with which code would be published to the centralized server and possible loss if all of the working copies were to disappear. Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.
dspillett 16y ago
This and more of the same. One loony (who I now thankfully don't have to put up with any more) was always making changes without merging them back into source control, meaning things were marked as addressed in issues logs but there was no corresponding update in the source tree. Lucky we were using a checkout-and-lock model at the time (small team, with each of us generally working on distcint areas, so this didn't work out too inconvenient as it can do with larger teams) meaning we could see what files he had checked out. And sometimes he'd just edit local copies of files without checking them out/in at all, and often "lost" updates somehow (usually, I think, accidentally overwriting them with the source controlled versions he'd not updated). <Deity> alone knows how much confusion he could have caused with his own local repository. He might have worked for weeks without pushing to elsewhere then lose the whole local repo. Then again I usually felt safer if his work wasn't in source control anyway. I often thought it might be quicker to stay late and do the work myself from the start instead of staying late fixing his work as often as I needed to...
- calloc 16y ago
  Company I work at has everyone have their own clone server side, they then clone it locally, any changes they make get pushed back up to their clone on the server, from there they can ask for a merge request to merge it into mainline.
  - dspillett 16y ago
    Aye, while he was still with us the chance to protect the central repository from any unverified changes from him was a very attractive idea. But given that he couldn't even file bug reports properly I'm not sure he would have coped with git.

jarin 16y ago

It's not hard to push topic branches to origin and delete them when they're done (although admittedly the syntax to delete a remote branch is a little strange). Just because the user has a risk of doing that doesn't reflect badly on the tool, though. It's like saying that the big risk of a knife is that you'll cut yourself if you're not careful.

jevinskie 16y ago

I fail to see your point. Every copy of a git repo is a full copy [1] - unlike a svn checkout. If you follow a centralized server model with git you have a copy on the server and every workstation it is checked out on. With svn, the full repo only exists on the server. Why couldn't you have a redundant, backed up central git server? [1] Not a substitute for real backups of your repo!

edabobojr 16y ago
Whenever people talk about git, they seem to talk about how you can have all of these working copies locally. My concern is the frequency with which code would be published to the centralized server and possible loss if all of the working copies were to disappear. Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.

dspillett 16y ago

This and more of the same. One loony (who I now thankfully don't have to put up with any more) was always making changes without merging them back into source control, meaning things were marked as addressed in issues logs but there was no corresponding update in the source tree. Lucky we were using a checkout-and-lock model at the time (small team, with each of us generally working on distcint areas, so this didn't work out too inconvenient as it can do with larger teams) meaning we could see what files he had checked out. And sometimes he'd just edit local copies of files without checking them out/in at all, and often "lost" updates somehow (usually, I think, accidentally overwriting them with the source controlled versions he'd not updated). <Deity> alone knows how much confusion he could have caused with his own local repository. He might have worked for weeks without pushing to elsewhere then lose the whole local repo. Then again I usually felt safer if his work wasn't in source control anyway. I often thought it might be quicker to stay late and do the work myself from the start instead of staying late fixing his work as often as I needed to...

calloc 16y ago
Company I work at has everyone have their own clone server side, they then clone it locally, any changes they make get pushed back up to their clone on the server, from there they can ask for a merge request to merge it into mainline.
- dspillett 16y ago
  Aye, while he was still with us the chance to protect the central repository from any unverified changes from him was a very attractive idea. But given that he couldn't even file bug reports properly I'm not sure he would have coped with git.