Timeline for Extreme Programming Daily Commits
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 11, 2013 at 19:38 | comment | added | btilly | See moishelettvin.blogspot.com/2006/11/… for a description of how at Microsoft they routinely had SCM level integration months later, and how this hurt development across the company. (That said, when you get large enough, there are scalability problems with revision control no matter how you slice it.) | |
| Mar 11, 2013 at 19:27 | comment | added | btilly | @MichaelBorgwardt I've seen it when a big branch lands. It was as messy as you would expect. | |
| Mar 11, 2013 at 16:29 | comment | added | Michael Borgwardt | I've worked in multiple industry settings on large projects using SVN and even CVS, involving pretty heavyweight processes, and I've never seen anyone do SCM-level integration after 6 months, or even 3 months. | |
| Mar 11, 2013 at 16:13 | comment | added | user7433 | @BrianKnoblauch at work with former SVN users, I feel weird because I'm the only one committing a crapload of times per day. Committing 6+ times in one day and the last commit was a revert of all the previous commits. Former SVN users are too used to big commits and merges I think | |
| Mar 9, 2013 at 16:24 | comment | added | btilly | @Giorgio Sometimes commits naturally need to be large. For example a variable name search and replace. But if you've got a careful code review process in place, the first thing that happens when you shove a large commit at people is that they tell you to break it up into smaller commits before showing it to them. | |
| Mar 9, 2013 at 10:54 | comment | added | Giorgio | "Conflicts happen because 2 people are independently working on the same thing": My favourite reading on this topic is point 7 of this article: paulgraham.com/head.html And consider that the author's worked in projects with very tight schedules and his team had to be pretty agile to keep up with competitors. | |
| Mar 9, 2013 at 10:50 | comment | added | Giorgio | "Make commits small and easy to review.: Small commits are not always easier to review than committing all the changes together, sometimes you need to see the whole story in order to understand how the individual changes are related to each other. | |
| Mar 9, 2013 at 10:37 | vote | accept | jakstack | ||
| Mar 9, 2013 at 5:18 | comment | added | ipaul | Committing before going home is a legacy behavior that was a result of SCM systems locking files. So, if you called in sick the next day, no one could use your file. Fortunately, we no longer live like animals. I would much rather work with small, simple changes to the source code that can be easily evaluated rather than 25 file , 1400 line change sets (commits) that no one can follow. | |
| Mar 9, 2013 at 2:24 | comment | added | hurricaneMitch | This method of integration, when coupled with automated tests that require passing before committing, ensures far less debugging disasters down the line. | |
| Mar 8, 2013 at 20:34 | comment | added | Jörg W Mittag | When practicing Atomic Coding and BDD, and working efficiently in a productive language, I don't find it uncommon to commit multiple times per minute. It wouldn't even occur to me to commit only once per day. | |
| Mar 8, 2013 at 19:50 | comment | added | Brian Knoblauch | I'm always amazed that there are people that don't commit multiple times per day. Making small changes and merging repeatedly is the best way to avoid horrible debugging sessions in the future. | |
| Mar 8, 2013 at 19:48 | history | answered | btilly | CC BY-SA 3.0 |