Timeline for Business case for decentralized version control systems
Current License: CC BY-SA 2.5
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 31, 2017 at 1:29 | comment | added | james peckham | sigh branching and merging (aka 'multitasking') never made anyone's life better. | |
| Sep 14, 2011 at 0:22 | comment | added | Anonymous Type | The centralised server failure is only an issue if you are using a file based source control system. If your source code is in a database it's presumably being backed up offsite. | |
| May 21, 2011 at 16:01 | comment | added | Tamás Szelei | And also, I wouldn't underestimate the value of commit history. In a huge system it can be really valueable to see who and why did something to the code. | |
| Jan 8, 2011 at 10:04 | comment | added | Inca | @mason: but that is quite an assumption: 'as long as all the devs...". Because on small scale companies with even smaller scale projects, projects may live and are being used happily without anyone coding on it for a year or two. | |
| Jan 7, 2011 at 17:56 | comment | added | Mason Wheeler | A centralized server failure wouldn't take down all your code. Even if you didn't have backups, the worst it could do is take down your revision history. But as long as all the developers have the code checked out, it exists in current form on their systems too. | |
| Jan 7, 2011 at 17:05 | comment | added | Michael Shaw | In a large business environment, you would have server redundancy. In a small business such server redundancy is not so certain. | |
| Jan 7, 2011 at 14:30 | comment | added | JBRWilkinson | In a business environment, the 'centralized server' would have redundancy, backup and admins responsible for keeping it (and all other servers) alive. | |
| Jan 7, 2011 at 3:32 | history | answered | mbreedlove | CC BY-SA 2.5 |