http://www.codewrecks.com/blog/index.php/2008/09/05/favor-small-and-frequent-checkin-over-big-ones/ Wrecks of code floating in the sea of Internet By Ricci Gian Maria Thu, 09 Feb 2012 16:15:12 +0000 hourly 1 http://wordpress.org/?v=3.2 http://www.codewrecks.com/blog/index.php/2008/09/05/favor-small-and-frequent-checkin-over-big-ones/comment-page-1/#comment-1749 alkampfer Fri, 05 Sep 2008 20:09:45 +0000 http://www.codewrecks.com/blog/index.php/2008/09/05/favor-small-and-frequent-checkin-over-big-ones/#comment-1749 Yes, more time you spent with local checkout, more merge work you will have to do when you commit, and if the time is really high.....merge is a nightmare. Yes, more time you spent with local checkout, more merge work you will have to do when you commit, and if the time is really high…..merge is a nightmare.

]]> http://www.codewrecks.com/blog/index.php/2008/09/05/favor-small-and-frequent-checkin-over-big-ones/comment-page-1/#comment-1748 Mark Fri, 05 Sep 2008 19:18:46 +0000 http://www.codewrecks.com/blog/index.php/2008/09/05/favor-small-and-frequent-checkin-over-big-ones/#comment-1748 Prior to Scrum, we were following a pretty typical Waterfall model and one of the challenges we were facing was creating different kinds of project branches in VSS. You can branch out the code but it is still just different folders. We would do the development in each of these folders (project branches) but the merging of the releases became almost impossible as we got bigger. The biggest overhead we were facing was in the merges and making sure that changes that are supposed to have been brought up to the same baseline were done accurately. We had to allocate a week or so with one or two developers making sure that after a given release was done, that all the changes were propagated. If we had a ticket that had to be fixed and now there were four project branches that were active at any given point in time, you would have to manually apply those changes in those four places because there wasn’t an easy way to propagate them back to the parent and merge them all together. We now are able to do private check ins that Accurev has that is just incredible for us, at least in my opinion, because that lets the developer work locally in a way somewhat disconnected but at the same time connected because the server is always keeping track of all the changes. Before I could bring the code locally to my lap top, I could work for 15 days, and wouldn’t know a thing about what I changed. Only at a point when I was ready to check in, I would just check in without knowing that I would be in conflict with something else or not. This post was interesting for me because those things were really a nightmare for us to manage. We had situations where one developer would overwrite another developer because they were working off an old baseline and those types of things. We survived it, but the project teams were not as big as they are now, so it was somewhat manageable because the number of people making the changes was somewhat limited. And then the way we had structured our code was that they would have 2 separate branches where 2 separate teams would work, so we had physical separation and every time we were doing a feature development in one and it had to be quickly made available to the other it was almost an impossible task. Because your baselines would be different, the merges would not be so easy and all kinds of issues would arise. Incremental merging and not putting off until the end of an iteration has been key. Prior to Scrum, we were following a pretty typical Waterfall model and one of the challenges we were facing was creating different kinds of project branches in VSS. You can branch out the code but it is still just different folders. We would do the development in each of these folders (project branches) but the merging of the releases became almost impossible as we got bigger. The biggest overhead we were facing was in the merges and making sure that changes that are supposed to have been brought up to the same baseline were done accurately. We had to allocate a week or so with one or two developers making sure that after a given release was done, that all the changes were propagated. If we had a ticket that had to be fixed and now there were four project branches that were active at any given point in time, you would have to manually apply those changes in those four places because there wasn’t an easy way to propagate them back to the parent and merge them all together. We now are able to do private check ins that Accurev has that is just incredible for us, at least in my opinion, because that lets the developer work locally in a way somewhat disconnected but at the same time connected because the server is always keeping track of all the changes. Before I could bring the code locally to my lap top, I could work for 15 days, and wouldn’t know a thing about what I changed. Only at a point when I was ready to check in, I would just check in without knowing that I would be in conflict with something else or not. This post was interesting for me because those things were really a nightmare for us to manage. We had situations where one developer would overwrite another developer because they were working off an old baseline and those types of things. We survived it, but the project teams were not as big as they are now, so it was somewhat manageable because the number of people making the changes was somewhat limited. And then the way we had structured our code was that they would have 2 separate branches where 2 separate teams would work, so we had physical separation and every time we were doing a feature development in one and it had to be quickly made available to the other it was almost an impossible task. Because your baselines would be different, the merges would not be so easy and all kinds of issues would arise. Incremental merging and not putting off until the end of an iteration has been key.

]]> http://www.codewrecks.com/blog/index.php/2008/09/05/favor-small-and-frequent-checkin-over-big-ones/comment-page-1/#comment-1747 Bart Czernicki Fri, 05 Sep 2008 15:12:26 +0000 http://www.codewrecks.com/blog/index.php/2008/09/05/favor-small-and-frequent-checkin-over-big-ones/#comment-1747 I agree. This concept works nicely when combined with Agile Development like Scrum/TDD. Frequent check-ins with proper version/build labels allow for mananiging a solution deliverable a lot quicker. The bigger the project/team, the more frequent checkins the less pain you will have in the long run. I agree. This concept works nicely when combined with Agile Development like Scrum/TDD. Frequent check-ins with proper version/build labels allow for mananiging a solution deliverable a lot quicker. The bigger the project/team, the more frequent checkins the less pain you will have in the long run.

]]>